CAP дает возможность классифицировать распределенные системы (CA, CP, AP в http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP и пункты 3.2.1 — 3.2.3 в http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf). Но эти классы распределенных систем являются крайними случаями. Реальные системы или их части могут занимать промежуточное положение или быть гибридными. Так как:

Consistency — в теореме сформулировано требованием, того чтобы во всех вычислительных узлах в любой момент времени данные не противоречат друг другу. То есть устаревание кэша узла распределенной БД не допускается. На практике считается допустимым и даже необходимым, если конечные пользователи видят устаревшие данные. Если данные на мониторе будут меняться 20 раз в секунду, пользователю это не понравится. Но слишком устаревшие данные тоже плохо. Так что это требование на практике не формализуемо, завит от того какие именно данные имеются ввиду и кем они используются. Если из за использования устаревших данных была произведена некорректная транзакция, то такая транзакция откатывается. На практике это допустимо.

Availability — в теореме сформулировано требованием, того чтобы любой запрос к распределённой системе завершается корректным откликом. Это означает, что если удаленный ресурс не может выполнить запрос он должен сказать об этом, а не молчать. На практике на запросы к удаленным ресурсам ставятся таймауты. Если сработал таймаут пользователю либо предлагается сделать запрос позже, либо запрос ставится в очередь и с заданным интервалом времени делаются повторные попытки сделать запрос.

Partition tolerance — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций. Это значит, что если вы записали в одну из изолированных секций (секция — это множество узлов, между которым есть связь), а в другой секции потом читаете, Вам должны четко сказать что чтение в данный момент невозможно (жертвуем Consistency, класс AP) или задержать ответ пока связь между секциями не восстановится (жертвуем Availability, класс CP). На практике для одних данных допустим один вариант, для других другой.

Класс CA это когда в случае разделения системы на изолированные секции полностью блокируется запись во всех узлах всех секций, но чтение остаётся доступным.

CAP дает возможность классифицировать распределенные системы (CA, CP, AP в http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP и пункты 3.2.1 — 3.2.3 в http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf). Но эти классы распределенных систем являются крайними случаями. Реальные системы или их части могут занимать промежуточное положение или быть гибридными. Так как:

Consistency — в теореме сформулировано требованием, того чтобы во всех вычислительных узлах в любой момент времени данные не противоречат друг другу. То есть устаревание кэша узла распределенной БД не допускается. На практике считается допустимым и даже необходимым, если конечные пользователи видят устаревшие данные. Если данные на мониторе будут меняться 20 раз в секунду, пользователю это не понравится. Но слишком устаревшие данные тоже плохо. Так что это требование на практике не формализуемо, завит от того какие именно данные имеются ввиду и кем они используются. Если из за использования устаревших данных была произведена некорректная транзакция, то такая транзакция откатывается. На практике это допустимо.

Availability — в теореме сформулировано требованием, того чтобы любой запрос к распределённой системе завершается корректным откликом. Это означает, что если удаленный ресурс не может выполнить запрос он должен сказать об этом, а не молчать. На практике на запросы к удаленным ресурсам ставятся таймауты. Если сработал таймаут пользователю либо предлагается сделать запрос позже, либо запрос ставится в очередь и с заданным интервалом времени делаются повторные попытки сделать запрос.

Partition tolerance — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций. Это значит, что если вы записали в одну из изолированных секций (секция — это множество узлов, между которым есть связь), а в другой секции потом читаете, Вам должны четко сказать что чтение в данный момент невозможно (жертвуем Consistency, класс AP) или задержать ответ пока связь между секциями не восстановится (жертвуем Availability, класс CP). На практике для одних данных допустим один вариант, для других другой.

Класс CA это когда в случае разделения системы на изолированные секции полностью блокируется запись во всех узлах всех секций, но чтение остаётся доступным.