ACGkaka的博客

一致性哈希分片：哈希分片的改进，把存储节点和需要存储的数据都存放在一个hash环上，数据根据hash值在hash环上按顺时针方向找到对应的数据存储结点上。一致性哈希分片的方式在扩充缓存结点时，只需要对少量数据进行存储位置的更新，而哈希分片需要对几乎所有数据进行存储位置更新。异步准实时更新方案：当数据库数据更新时，不立即更新缓存数据，而是将需要更新的操作记录成日志，再逐步排队完成更新。哈希分片：通过对key进行hash操作，可以把数据分配到不同实例，这类似于取余操作，余数相同的，放在一个实例上。

刘工的方案中，保留原有关系数据库，将 Redis 仅作为缓存，即热点数据缓存在 Redis 中，核心业务的结构化数据存储在原有院系数据库中。李工采用的方案中，采用 MemCache 作为缓存系统，但 MemCache 无法进行持久化，数据不能备份，只能用于缓存使用，数据全部存在于内存，一旦重启数据会全部丢失。​ 为避免数据可靠性和一致性的问题，刘工的方案采用 Redis 作为数据库缓存，请用 200 字以内的文字说明基本的 Redis 与原有关系数据库的数据同步方案。（3）客户端哈希分片/一致性哈希；

​ 缓存系统一般以 key/value 形式存储数据，在系统运维中发现，部分针对缓存的查询，未在缓存系统中找到对应的 key，从而引发了大量对数据库服务器的查询请求，最严重时甚至导致了数据库服务器的宕机。​ 运维团队发现在某些情况下，若大量的 key 设置了相同的失效时间，或者缓存系统重启等原因，都会造成数据库服务器请求瞬间爆量，引出大量缓存更新操作，导致整个系统性能极具下降，进而造成整个系统崩溃。存在双写不一致问题，在写数据时，可能存在缓存写成功，数据库写失败，或者反之，从而造成数据不一致。

开发团队最终选择了 RDB 方式。定期删除策略：Redis 默认会每秒进行 10 次过期扫描（100ms一次），过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心算法，从过期字典中随机 20 个 key，如果过期的 key 比率超过 1/4，那就会重复上一步骤。清选择题干描述的（a）~（g）功能选项，填入表 4-1 中（1）~（5）的空白处。惰性删除：除了定期遍历之外，它还会再客户端访问这个 key 的时候，对 key 的过期时间进行检查，如果过期了就立即删除，不会返回任何东西。

三、使用阿里的同步工具 cannal，cannal 实现方式是模拟 mysql slave 和 master 的同步机制，监控 DB binlog 的日志更新来触发缓存的更新，此种方法可以解放程序员双手、减少工作量，但再使用时有些局限性。用应用逻辑来实现数据的完整性风险较大，因为同一逻辑必须在所有的应用中使用和维护，容易遗漏，特别是在需求变化时，不易于维护。（1）批处理维护：指对复制列或派生列的修改积累一定的时间后，运行一批处理作业或存储过程对复制或派生列进行修改，这只能在对实时性要求不高的情况下使用。