根据业务需求可分为强一致性和最终一致性两种解决方案。
1.强一致性方案
当业务对数据一致性要求较高时,使用该方案。
一般通过降低性能的方式,对读写请求顺序做到可控,以保证在写操作在同步缓存的过程中不产生读操作。
这样在读操作时,读取到的缓存数据一定是数据库中相同的数据。
2.最终一致性
当业务要求只需保证数据的最终一致性,但对可用性要求较高时,使用该方案。
一般通过先修改数据库,再以非即时的方式修改缓存来保证数据的最终一致性。
根据修改缓存方式的不同,有如下方法。
2.1 删除缓存并设置缓存过期时间
在修改数据库成功后,删除原本的缓存数据。这时在读操作未命中缓存数据时,从数据库中更新最新数据。
但是当删除缓存失败或数据库提交不及时时,依然存在数据不一致的意外情况,因此需要给缓存设置过期时间,当意外情况发生时,等待缓存过期后更新缓存数据。
2.2 异步更新缓存
把修改缓存的操作独立出来,通过监听数据库更新的方式(例如订阅binlog日志)异步修改缓存数据。
当更新失败时使用重试机制保证更新成功。
当业务同时对一致性和可用性有较高要求时,根据分布式系统的CAP理论,只有放弃分区容错性来满足要求了。
标签:缓存,解决方案,数据库,更新,修改,缓存数据,一致性 来源: https://www.cnblogs.com/uip001/p/16561068.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。