❶ Redis-分布式缓存一致性解决方案
一致性Hash算法也使用取模的方法，刚才描述的取模法是对服务器的数量进行取模，而一致性Hash算法是对2^32取模
首先，我们把2^32 想象成一个圆，圆上一共有2^32 个点，编号0-2^32-1，这个圆称为hash环
❷ redis怎么保证数据的一致性
如果要“保证”数据的安全性，那么会带来开销的进一步提升，以至于使用redis带来的性能优势都会丧失。正确的做法是区分不同的业务，使得并不需要“保证”数据一致性的场合，可以使用redis优化。而敏感的场合依然使用mysql。
❸ Redis 如何保持和 MySQL 数据一致
redis在启动之后，从数据库加载数据。
读请求：
不要求强一致性的读请求，走redis，要求强一致性的直接从mysql读取
写请求：
数据首先都写到数据库，之后更新redis（先写redis再写mysql，如果写入失败事务回滚会造成redis中存在脏数据）
在并发不高的情况下，读操作优先读取redis，不存在的话就去访问MySQL，并把读到的数据写回Redis中；写操作的话，直接写MySQL，成功后再写入Redis(可以在MySQL端定义CRUD触发器，在触发CRUD操作后写数据到Redis，也可以在Redis端解析binlog，再做相应的操作)
在并发高的情况下，读操作和上面一样，写操作是异步写，写入Redis后直接返回，然后定期写入MySQL
1.当更新数据时，如更新某商品的库存，当前商品的库存是100，现在要更新为99，先更新数据库更改成99，然后删除缓存，发现删除缓存失败了，这意味着数据库存的是99，而缓存是100，这导致数据库和缓存不一致。
解决方法：
这种情况应该是先删除缓存，然后在更新数据库，如果删除缓存失败，那就不要更新数据库，如果说删除缓存成功，而更新数据库失败，那查询的时候只是从数据库里查了旧的数据而已，这样就能保持数据库与缓存的一致性。
2.在高并发的情况下，如果当删除完缓存的时候，这时去更新数据库，但还没有更新完，另外一个请求来查询数据，发现缓存里没有，就去数据库里查，还是以上面商品库存为例，如果数据库中产品的库存是100，那么查询到的库存是100，然后插入缓存，插入完缓存后，原来那个更新数据库的线程把数据库更新为了99，导致数据库与缓存不一致的情况
解决方法：
遇到这种情况，可以用队列的去解决这个问，创建几个队列，如20个，根据商品的ID去做hash值，然后对队列个数取摸，当有数据更新请求时，先把它丢到队列里去，当更新完后在从队列里去除，如果在更新的过程中，遇到以上场景，先去缓存里看下有没有数据，如果没有，可以先去队列里看是否有相同商品ID在做更新，如果有也把查询的请求发送到队列里去，然后同步等待缓存更新完成。
这里有一个优化点，如果发现队列里有一个查询请求了，那么就不要放新的查询操作进去了，用一个while（true）循环去查询缓存，循环个200MS左右，如果缓存里还没有则直接取数据库的旧数据，一般情况下是可以取到的。
1、读请求时长阻塞
由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时间内返回，该解决方案最大的风险在于可能数据更新很频繁，导致队列中挤压了大量的更新操作在里面，然后读请求会发生大量的超时，最后导致大量的请求直接走数据库，像遇到这种情况，一般要做好足够的压力测试，如果压力过大，需要根据实际情况添加机器。
2、请求并发量过高
这里还是要做好压力测试，多模拟真实场景，并发量在最高的时候QPS多少，扛不住就要多加机器，还有就是做好读写比例是多少
3、多服务实例部署的请求路由
可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过nginx服务器路由到相同的服务实例上
4、热点商品的路由问题，导致请求的倾斜
某些商品的读请求特别高，全部打到了相同的机器的相同丢列里了，可能造成某台服务器压力过大，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以更新频率不是太高的话，这个问题的影响并不是很大，但是确实有可能某些服务器的负载会高一些。
img
搜索微信号（ID：芋道源码），可以获得各种 Java 源码解析。
并且，回复【书籍】后，可以领取笔者推荐的各种 Java 从入门到架构的书籍。
❹ redis 数据分区--一致性hash&&虚拟槽分区
1.节点区域分区:
使用特定的数据,如redis的键或用户ID,再根据节点数量N使用公式:hash(key)%N计算出hash值,用来决定数据映射到哪一个节点上.
这种方案的问题是:
当节点数量变化时,需要重新计算hash,会导致数据的重新迁移.
2.一致性hash算法
一致性hash算法实现思路是为系统中每一个节点分配一个token,范围在0~2^32,这些token构成一个hash环.数据的读写执行节点查找操作时,先根据key计算hash值,然后顺时针找到第一个大于等于该hash的token节点.
好处:
这种方式最大的好处就是,在加入或删除节点时,只影响hash环中相邻的两个节点,对其他节点无影响.
问题:
3.虚拟槽算法
使用分散度较好的hash函数,将所有的数据映射到 比如0~16383(2^14)范围的槽中(slot).这个槽的数量一般远远大于实例的数量.
槽是集群数据管理和迁移的基本单位.采用大范围槽的主要目的是为了方便数据拆分和集群扩展.
每一个实例会映射一部分范围的槽.
特点:
1.解耦数据和节点之间的关系,简化扩容和锁容的难度
2.节点自身维护槽的映射关系,不需要客户端或代理服务维护槽分区的元数据.
3.支持节点,槽,键之间的映射查询,用于数据路由,在线伸缩灯场景.
HashTags（面试）
Mset k1 v1 k2 v2 k3 v3
通过分片手段，可以将数据合理的划分到不同的节点上，这本来是一件好事。但是有的时候，我们希望对相关联的业务以原子性方式进行操作。举个简单的例子
我们在单节点上执行MSET （m表示多个，一次向redis设置多个key和值）, 它是一个原子性的操作，我们要求所有给定的key要在同一时间内被设置，不能出现某些指定的key被更新另一些指定的key没有被更新的情况。但是在集群环境下，我们仍然可以执行MSET命令，但它的操作不在是原子操作，会存在某些指定的key被更新，而另外一些指定的key没有改变，原因是多个key可能会被分配到不同的机器上。
所以，这里就会存在一个矛盾点，及要求key尽可能的分散在不同机器，又要求某些相关联的key分配到相同机器。
这个也是在面试的时候会容易被问到的内容。怎么解决呢？
从前面的分析中我们了解到，分片其实就是一个hash的过程，对key做hash取模然后划分到不同的机器上。所以为了解决这个问题，我们需要考虑如何让相关联的key得到的hash值都相同呢？如果key全部相同是不现实的，所以怎么解决呢？在redis中引入了HashTag的概念，可以使得数据分布算法可以根据key的某一个部分进行计算，然后让相关的key落到同一个数据分片；
举个简单的例子，假如对于用户的信息进行存储，
redis:store:1001、redis:store:1002
那么通过hashtag的方式，
redis:{store}:1001、redis:{store}:1002; 表示
当一个key包含 {} 的时候，就不对整个key做hash，而仅对 {} 包括的字符串做hash。
❺ redis集群使用一致性hash吗
使用。
设定一个圆环上 0-2^3̂2-1 的点，每个点对应一个缓存区，每个键值对存储的位置也经哈希计算后对应到环上节点。但现实中不可能有如此多的节点，所以倘若键值对经哈希计算后对应的位置没有节点，那么顺时针找一个节点存储它。
1、考虑增加服务器节点的情况，该节点顺时针方向的数据仍然被存储到顺时针方向的节点上，但它逆时针方向的数据被存储到它自己。这时候只有部分数据会失效，被映射到新的缓存区。
2、考虑节点减少的情况。该缺失节点顺时针方向上的数据仍然被存储到其顺时针方向上的节点，设为 beta，其逆时针方向上的数据会被存储到 beta 上。同样，只有有部分数据失效，被重新映射到新的服务器节点。
(5)redis数据库一致性扩展阅读：
一致性哈希算法
这种方法可以应对节点失效的情况，当某个分布式集群节点宕机，服务请求可以通过hash算法重新分配到其他可用的服务器上。避免了无法处理请求的状况出现 。
但这种方法的缺陷也很明显，如果服务器中保存有服务请求对应的数据，那么如果重新计算请求的hash值，会造成大量的请求被重定位到不同的服务器而造成请求所要使用的数据失效，这种情况在分布式系统中是非常糟糕的。
一个设计良好的分布式系统应该具有良好的单调性，即服务器的添加与移除不会造成大量的哈希重定位，而一致性哈希恰好可以解决这个问题。
❻ 97 基于Binlog实现MySQL与Redis数据一致性问题
mysql 与Redis 数据一致性问题 直接将Redis清空
中间件 canal框架 基于 docker环境构建
canal 框架 原理：
<u>https://gitee.com/mirrors/canal?utm_source=alading&utm_campaign=repo</u>
canal 框架原理
1，canal伪装成mysql从节点 订阅mysql 主节点的binlog文件
2，当我们的mysql 主节点 binlog 文件发生了变化，则将binlog 文件发送给canal服务器端
3，canal 服务器端将该binlog 文件二进制转换成json格式给canal客户端
4，canal客户端在将改数据同步到Redis/ES
基于Binlog 开启方式
1.mysql 开启binlog 文件配置
windows 配置
查询 my.ini配置文件位置
C:\ProgramData\MySQL\MySQL Server 5.7
2， linux mysql
安装canal
进入容器
编辑配置文件
重启canal
Docker-compose 构建canal
canal.instance.mysql.slaveId：slaveId不能与mysql的serverId一样
canal.instance.master.address：mysql地址
canal.instance.dbUsername：mysql账号
canal.instance.dbPassword：mysql密码
❼ Redis主从复制与一致性
数据的同步过程一般都涉及到全量数据的迁移以及后续增量数据的同步。
在主Master接收到SYNC命令之后，它会执行bgsave在后台生成一个RDB文件，并且使用一个缓冲区记录从现在开始执行所有写命令。当bgsave生成的RDB文件完成了之后，它就发送给从服务器去进行载入。在更新状态完成之后，Master再将记录在缓冲区里面的新命令发送给从服务器，这样从服务器进行执行，主从服务器就保持了一致状态。
从服务器到主服务器的复制可以分为两种情况:
为了解决SYNC在处理断线重复制时候的低效问题，Redis从2.8版本之后开始使用PSYNC命 令，它支持完整重同步和部分重同步。 完整重同步和SYNC一样，部分重同步就是在处理断 线重新连接之后，主节点只向从节点发送链接断开期间的写命令，它的实现基于以下三部分:
缺点：
注：上述所有场景的前提是数据依然保存在backlog中，否则还是会进行完全重同步。
如果slave可以收到每条传播指令，并执行成功，便可以保持与master的数据一致状态。但是master并不等待slave节点的返回，master与slave是通过网络通信，由于网络抖动等因 素，命令传播过程不保证slave真正接收到，那如何在传播阶段确保主从数据一致呢?
在命令传播阶段，每隔一秒slave节点向master节点发送一次心跳信息，命令格式为 REPLCONF ACK <offset>。其中offset指从节点保存的复制偏移量。REPLCONF ACK命令的作用包括:
在全量复制阶段，主节点会将执行的写命令放到复制缓冲区中，该缓冲区存放的数据包括了以下几个时间段内主节点执行的写命令:bgsave生成RDB文件、RDB文件由主节点发往从 节点、从节点清空老数据并载入RDB文件中的数据。当主节点数据量较大，或者主从节点之间网络延迟较大时，可能导致该缓冲区的大小超过了限制，此时主节点会断开与从节点之间的连接;这种情况可能引起全量复制→复制缓冲区溢出导致连接中断→重连→全量复制→复制缓冲区溢出导致连接中断......的循环。
复制缓冲区的大小由client-output-buffer-limit slave{hard limit}{soft limit}{soft seconds}配 置，默认值为client-output-buffer-limit slave 256MB 64MB 60，其含义是:如果buffer大于 256MB，或者连续60s大于64MB，则主节点会断开与该从节点的连接。该参数是可以通过 config set命令动态配置的(即不重启Redis也可以生效)。
Redis为复制积压缓冲区设置的默认大小为1MB，如果主服务器需要执行大量写命令，又或者主从服务器断线后重连接所需的时间比较⻓，那么这个大小也许并不合适。如果复制积压 缓冲区的大小设置得不恰当，那么PSYNC命令的复制重同步模式就不能正常发挥作用，正确估算和设置复制积压缓冲区的大小非常重要。
复制积压缓冲区的最小大小可以根据公式second*write_size_per_second 来估算:
❽ 算法简述：一致性hash环，与redis 槽道原理
1.哈希算法 对服务器个数进行模余存储，
（下图）
传统新增节点 （下图）
2、哈希环，应用于数据的分布式存储，在增删节点之间，能够尽可能少的迁移数据，保证多数数据的一致性。（下图）每个节点代表一个数据存储服务器。服务器在通过哈希算法过后，得到一个固定长度数值a, 由a/65535 模余 得0~65535之间正整数，散列分布在hash环上（下图）
蓝色代表数据，绿色代表数据存储库，每个数据存储库 管理顺时针 ，上个节点之间的区域。（下图）图中数字 因该是对65536取余数
在新增节点4 后，只有数据a需要迁移（下图）
3，槽道原理，综上所述 ，哈希环减少了 数据在存储节点增删 过程中对数据产生的影响。redis 提出的hash槽道，则让数据迁移变得更为灵活
❾ redis如何与数据库数据同步
数据库同步到Redis
我们大多倾向于使用这种方式，也就是将数据库中的变化同步到Redis，这种更加可靠。Redis在这里只是做缓存。
方案1 （推荐学习：Redis视频教程）
做缓存，就要遵循缓存的语义规定：
读：读缓存redis，没有，读mysql，并将mysql的值写入到redis。
写：写mysql，成功后，更新或者失效掉缓存redis中的值。
对于一致性要求高的，从数据库中读，比如金融，交易等数据。其他的从Redis读。
这种方案的好处是由mysql，常规的关系型数据库来保证持久化，一致性等，不容易出错。
方案2
这里还可以基于binlog使用mysql_udf_redis，将数据库中的数据同步到Redis。
但是很明显的，这将整体的复杂性提高了，而且本来我们在系统代码中能很轻易完成的功能，现在需要依赖第三方工具，而且系统的整个边界扩大了，变得更加不稳定也不好管理了。
❿ 分布式redis怎么保证数据一致性
Redis 默认是单机环境使用的。数据量较大时需要shard（多机环境），这个时候要用ShardedJedis。ShardedJedis是基于一致性哈希算法实现的分布式Redis集群客户端