Как такая компания, как Amazon, избегает узких мест в доступе к слою базы данных?

Если вы представляете такую ​​компанию, как Amazon (или любое другое крупное веб-приложение для электронной коммерции), которая эксплуатирует интернет-магазин в больших масштабах и имеет лишь ограниченное количество физических товаров на своих складах, как они могут оптимизировать это так, чтобы не было одно узкое место? Конечно, у них должно быть несколько баз данных с репликацией и множество серверов, которые обрабатывают нагрузку независимо. Однако, если несколько пользователей обслуживаются отдельными серверами и оба пытаются добавить один и тот же товар в свою корзину, для которого остается только один, должен существовать некоторый «источник правды» для количества, оставшегося для этого товара. Не означает ли это, что, по крайней мере, все пользователи, имеющие доступ к информации о продукте для одного элемента, должны запрашивать одну и ту же базу данных последовательно?

Я хотел бы понять, как вы можете управлять таким большим магазином, используя распределенные вычисления, а не создавать огромное узкое место в одной БД, содержащей информацию об инвентаризации.

Однако, если несколько пользователей обслуживаются отдельными серверами и оба пытаются добавить один и тот же товар в свою корзину, для которого остается только один, должен существовать некоторый «источник правды» для количества, оставшегося для этого товара.

На самом деле, нет. Это не проблема, которая требует совершенного технического решения на 100%, потому что оба случая ошибок имеют бизнес-решение, которое не очень дорого:

• Если вы неправильно сообщаете пользователю, что товар распродан, вы теряете продажу. Если вы продаете миллионы предметов каждый день, и это происходит, может быть, один или два раза в день, это теряется в шуме.
• Если вы принимаете заказ и в процессе его обработки обнаруживаете, что у вас закончился товар, вы просто сообщаете об этом клиенту и оставляете ему возможность дождаться пополнения или отмены заказа. У вас есть один слегка раздраженный клиент. Опять же, не проблема, когда 99,99% заказов работают нормально.

На самом деле, я недавно сам столкнулся со вторым случаем, так что это не гипотетически: именно так и происходит, и как Amazon справляется с этим.

Это концепция, которая часто применяется, когда у вас есть проблема, которую теоретически очень трудно решить (будь то с точки зрения производительности, оптимизации или чего-то еще): вы часто можете жить с решением, которое действительно хорошо работает в большинстве случаев, и признать, что оно иногда сбои, если вы можете обнаружить и обработать сбои, когда они происходят.

Сочетание

• хеширования
• Sharding
• копирование
• распределение
• высокий отказоустойчивость
• хранилища ключей

Там нет магии, просто все более и более сложные ситуации. Так же, как DNS, он сделан в масштабе.

«Единая версия правды» является частью таких систем. Генерация нового ключа становится более сложной операцией, чем просто генерация следующего числа в последовательности. Например, существуют другие последовательности. Это та сложность, с которой могут справляться системы распределенных баз данных, и они делают это, выполняя несколько операций с компонентами при создании новых объектов, делая их доступными для других, обеспечивая уникальность последовательностей в случае необходимости, составных ключей и т. Д. ,

Я видел проблему «Последний товар на складе», решенную следующим образом:

Ежедневно обновляйте все уровни запасов и помечайте товары как высокие, низкие, категории заказов или товаров со склада в соответствии с пороговыми уровнями.

Очевидно, что это «товары со склада», которые являются проблематичными

• Товары с высоким запасом

Не беспокойтесь о проверке уровня запасов. Просто разместите заказ

• Товары с низким уровнем запасов

Предупредить пользователя при просмотре «Последние несколько осталось!». когда они идут, чтобы заплатить, проверьте и уменьшите уровень запаса. Если его нет в наличии, обновите статус товара.

Таким образом, вы попадаете в базу данных только для товаров с «низким запасом», и вы делаете это только тогда, когда покупатель находится в процессе покупки. Стоимость заключается в том, что некоторые клиенты не смогут завершить покупку.

Однако в большинстве случаев «нет в наличии» на самом деле означает, что вы ожидаете другую доставку, поэтому вы все равно хотите принять заказ и, возможно, просто выдать предупреждение или ограничить варианты доставки. Таким образом, эти клиенты не потеряны.

Во время высоких нагрузок, таких как продажи, вы можете даже отключить проверку запасов и просто отправить электронное письмо клиентам позже: «Извините, у нас кончился X, хотите ли вы Y»

По сути, цель любой платформы электронной коммерции никогда не читается из базы данных. Всегда обслуживайте кэшированные страницы и делайте все на стороне клиента.

В этом видео Мартин Фаулер обсуждает базы данных NoSQL:

https://www.youtube.com/watch?v=qI_g07C_Q5I

Один из моментов (где-то там) заключается в том, что такие места, как Amazon, скорее будут радовать 99% людей, принимая их заказ, не имея возможности проверить «наверняка», действительно ли он доступен, и, возможно, раздражать очень маленький процент, имея сказать "извините, похоже, кто-то избил тебя до этого".

Иными словами, для описываемого вами сценария нет реальной обработки, просто Amazon использует выгоду от сомнений, основанных на последнем успешном прочтении инвентаря, и в случае промежуточной транзакции между ними - упс.

(кстати, это отличное видео, если вам интересно узнать о NoSQL)