标签：提前 port twemproxy 根据 png 隔离 基于 mic 实现
目标是实现redis集群的无感知弹性扩容
关键点
1.是无感知，即对redis集群的用户来说服务ip和port保持不变
2.弹性扩容，指的是在需要时刻可以按照业务扩大redis存储容量。
1.业务场景
- 1.redis集群某个业务容量不足，需要扩容
- 2.redis集群需要一个为一个新业务分配存储容量
- 3.redis集群在扩容的时候服务不是停止的，而是服务中，即无感知
最好的解决方式
对客户端无感知，即客户端不需要任何操作就实现了redis集群的扩容
2.最朴素的twemproxy+redis集群架构
其中twemproxy-A代理后面接了3个redis实例，作为集群使用，如果1个redis示例有10G存储能力，
那么目前这个架构具有10G*3=30G的存储能力，其中根据twemproxy的配置来实现负载均衡。
3.最直接的扩容方案：
这个方案扩容是最直接的，即在代理后面直接新加一个redis-4，来扩充这个redis集群的容量。
这种方式最直接，但是问题也比较大，主要有2个：
- 1.后端新增一个redis实例之后，虽然有一致性hash保证大部分数据还会走原先的路由，
- 但仍有小部分旧的数据会被路由到新的redis-4中，即丢失一小部分旧的数据
- 2.扩容效果不理想，一开始时，redis-4的已用存储是0，理想最好的方式是旧的数据还走之前的路由
- ，新的数据路由到redis-4中
为了解决上述方案的不足，本文提出了一个新的方案如下
4.一个twemproxy二级代理的方案：
这个方案有1个关键点，即怎么实现旧的数据走之前的路由，新的数据走redis-4的路由，这就用到了
hash_tag的预分配(即提前占坑的思想)技术，使用hash_tag作为二级twemproxy的路由标示，具体操作如下：
- 1.twemproxy-C的hash_tag 设置为(),twemproxy-A和twemproxy-B的hash_tag设置为{}
- 2.插入形如key_(0)_{1},key_(1)_{1}的2个key，假设key_(0)_{1}路由到了twemproxy-A，key_(1)_{1}路由到了twemproxy-B
- 3.那么旧的服务插入数据的标示就是key_(0)_{xxxx}，新的数据插入的标示就是key_(1)_{xxxx}
注意点如下：
- 1.一开始可以预先分配多一些二级代理，以备不时只需
- 2.一开始需要测试清楚，哪些()标示走哪些对应的二级代理。
好处：
- 1.自动的完成了旧的数据走旧路由，新的数据走新路由
- 2.新的数据也可以如图与之前的业务数据存储完全隔离
- 3.新的路由还可以复用之前的存储，即redis-1到redis-3的存储
5.最终真正实现无感知弹性扩容方案
如图4所示：
最终的方案新增了一个VIP，用这个VIP来解决无感知的问题，即扩容对客户端来说是无感知的。
无感知的解决类似”双buffer交换“的思路，即上图的twemproxy-C和twemproxy-D，当需要重启twemproxy代理时，
可以进行如下操作：
- 1.现假设vip只访问到twemproxy-C
- 2.更改twemproxy-D使用最新的配置，重启
- 3.vip切换服务到只访问twemproxy-D
当还需要重启代理时，以此循环。
基于twemproxy和vip实现redis集群的无感知弹性扩容
标签：提前 port twemproxy 根据 png 隔离 基于 mic 实现
原文地址：https://www.cnblogs.com/wendy009/p/11383655.html
