Автор оригинала: Vlad Mihalcea.
Каждая новая глава моей книги выходит сразу после ее завершения, поэтому читателю не нужно ждать, пока вся часть будет закончена, чтобы получить доступ к новому материалу.
В этой главе объясняется, как работает корпоративное кэширование, от внутренних буферов базы данных до кэширования на уровне приложений и кэша второго уровня, предлагаемого Hibernate.
16. Caching 16.1 Caching flavors 16.2 Cache synchronization strategies 16.2.1 Cache-aside 16.2.2 Read-through 16.2.3 Write-invalidate 16.2.4 Write-through 16.2.5 Write-behind 16.3 Database caching 16.4 Application-level caching 16.4.1 Entity aggregates 16.4.2 Distributed key/value stores 16.4.3 Cache synchronization patterns 16.4.4 Synchronous updates 16.4.5 Asynchronous updates 16.4.5.1 Change data capture 16.5 Second-level caching 16.5.1 Enabling the second-level cache 16.5.2 Entity cache loading flow 16.5.3 Entity cache entry 16.5.3.1 Entity reference cache store 16.5.4 Collection cache entry 16.5.5 Query cache entry 16.5.6 Cache concurrency strategies 16.5.6.1 READ_ONLY 16.5.6.1.1 Inserting READ_ONLY cache entries 16.5.6.1.2 Updating READ_ONLY cache entries 16.5.6.1.3 Deleting READ_ONLY cache entries 16.5.6.2 NONSTRICT_READ_WRITE 16.5.6.2.1 Inserting NONSTRICT_READ_WRITE cache entries 16.5.6.2.2 Updating NONSTRICT_READ_WRITE cache entries 16.5.6.2.3 Risk of inconsistencies 16.5.6.2.4 Deleting NONSTRICT_READ_WRITE cache entries 16.5.6.3 READ_WRITE 16.5.6.3.1 Inserting READ_WRITE cache entries 16.5.6.3.2 Updating READ_WRITE cache entries 16.5.6.3.3 Deleting READ_WRITE cache entries 16.5.6.3.4 Soft locking concurrency control 16.5.6.4 TRANSACTIONAL 16.5.6.4.1 XA_Strict mode 16.5.6.4.2 XA mode 16.5.6.4.3 Inserting TRANSACTIONAL cache entries 16.5.6.4.4 Updating TRANSACTIONAL cache entries 16.5.6.4.5 Deleting TRANSACTIONAL cache entries 16.5.7 Query cache strategy 16.5.7.1 Table space query invalidation 16.5.7.2 Native SQL statement query invalidation
Кэширование присутствует везде, и корпоративные системы ничем не отличаются. Прежде чем перейти к кэшированию на уровне приложений, важно знать, что большинство систем баз данных предназначены для использования кэширования, насколько это возможно. Некоторые системы баз данных поставляются со своими собственными общими буферами, в то время как другие полагаются на базовую операционную систему для кэширования дисковых страниц в памяти.
Даже после настройки базы данных для преодоления сетевых накладных расходов и повышения уровня трафика обычно используется кэш уровня приложения, например Redis или Memcached. Эти хранилища значений ключей могут быть распределены на нескольких узлах, что обеспечивает повышенную доступность и возможности сегментирования данных. Одним из основных преимуществ хранения агрегатов сущностей в базе данных с ключевыми значениями является то, что приложение может работать в режиме только для чтения, даже если весь кластер баз данных отключен для обслуживания.
Единственным недостатком использования кэша уровня приложения является обеспечение того, чтобы два отдельных источника данных не расходились. По этой причине существует несколько стратегий параллелизма кэша: отложенный кэш, сквозное чтение, сквозная запись.
Будучи тесно связанным с режимом гибернации, кэш второго уровня может ускорить чтение без ущерба для согласованности данных. Однако для выбора правильной стратегии cacheconcurrencystrategy ( ТОЛЬКО для ЧТЕНИЯ, НЕСТРОГАЯ ЗАПИСЬ , ЗАПИСЬ для ЧТЕНИЯ , ТРАНЗАКЦИЯ ) требуется понимание внутренней работы политики обновления кэша. Кэш запросов сущностей имеет свои собственные правила, и поскольку в нем используется агрессивная политика недействительности кэша, он применяется только к определенным критериям шаблона доступа к данным.
Глава о кэшировании, содержащая почти 60 страниц, является одной из самых больших глав этой книги, поэтому наслаждайтесь чтением высокопроизводительной сохраняемости Java !