|
Redis支持的数据结构 字符串（String） 哈希（Hash） 列表（List） 集合（Set） 有序集合（Sorted Set）位数组 HyperLogLog
Redis支持的操作Redis适用场景KV存储 缓存（TTL LRU...）消息中间件 分布式锁
Redis集群实现方式实现基础——分区分区是分割数据到多个Redis实例的处理过程，因此每个实例只保存key的一个子集。 通过利用多台计算机内存的和值，允许我们构造更大的数据库。 通过多核和多台计算机，允许我们扩展计算能力；通过多台计算机和网络适配器，允许我们扩展网络带宽。
集群的几种实现方式客户端分片原理如下所示： 特性 优点 缺点 业务逻辑与数据存储逻辑耦合 可运维性差 多业务各自使用redis，集群资源难以管理 不支持动态增删节点
基于代理的分片基本原理如下所示：
特性 透明接入Proxy 的逻辑和存储的逻辑是隔离的。 代理层多了一次转发，性能有所损耗。
路由查询基本原理如下所示：
集群的挑战 Redis集群各种方案原理TwemproxyTwemproxy高可用部署架构 Twemproxy特性redis的管道(Pipelining)操作是一种异步的访问模式，一次发送多个指令，不同步等待其返回结果。这样可以取得非常好的执行效率。调用方法如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 | @Test
public void testPipelined() {
Jedis jedis = new Jedis("localhost");
Pipeline pipeline = jedis.pipelined();
long start = System.currentTimeMillis();
for (int i = 0; i < 100000; i++) {
pipeline.set("p" + i, "p" + i);
}
List<Object> results = pipeline.syncAndReturnAll();
long end = System.currentTimeMillis();
System.out.println("Pipelined SET: " + ((end - start)/1000.0) + " seconds");
jedis.disconnect();
}
|
Twemproxy不足性能低：代理层损耗 && 本身效率低下 Redis功能支持不完善 集群功能不够完善 仅作为代理层使用 本身不提供动态扩容，透明数据迁移等功能
失去维护
Redis ClusterRedis Cluster模型Redis-cluster原理Gossip 算法又被称为反熵（Anti-Entropy），熵是物理学上的一个概念，代表杂乱无章，而反熵就是在杂乱无章中寻求一致，这充分说明了 Gossip 的特点：在一个有界网络中，每个节点都随机地与其他节点通信，经过一番杂乱无章的通信，最终所有节点的状态都会达成一致。每个节点可能知道所有其他节点，也可能仅知道几个邻居节点，只要这些节可以通过网络连通，最终他们的状态都是一致的，当然这也是疫情传播的特点。
简单的描述下这个协议，首先要传播谣言就要有种子节点。种子节点每秒都会随机向其他节点发送自己所拥有的节点列表，以及需要传播的消息。任何新加入的节点，就在这种传播方式下很快地被全网所知道。这个协议的神奇就在于它从设计开始就没想到信息一定要传递给所有的节点，但是随着时间的增长，在最终的某一时刻，全网会得到相同的信息。当然这个时刻可能仅仅存在于理论，永远不可达。
Redis-cluster请求路由方式查询路由的流程如下所示： Redis cluster采用这种架构的考虑：
Redis Cluster特性Redis Cluster不足CodisCodis部署拓扑Codis数据存储Codis模块简介Codis Server Codis Proxy 客户端连接的 Redis 代理服务, 实现了 Redis 协议。 对于同一个业务集群而言，可以同时部署多个 codis-proxy 实例 不同 codis-proxy 之间由 codis-dashboard 保证状态同步。
Codis Dashboard Codis Admin Codis FE Codis HA Storage
Codis主从切换Codis数据迁移流程前提：Codis单条数据迁移是原子操作 单条数据迁移过程：
迁移过程如下所示： 迁移过程中，Codis-dashboard与proxy通过zk通信，路由表信息全部存放在zk，保证所有proxy的视图一致。
Codis如何保证数据迁移过程的正确及透明？ codis-config 在实际修改slot状态之前，会确保所有的 proxy 收到这个迁移请求。 迁移过程中, 如果客户端请求 slot 的 key 数据,proxy 会将请求转发到group2上。
Codis VS Redis| 对比参数 | Codis | Redis-cluster |
|---|
| Redis版本 | 基于2.8分支开发 | >= 3.0 | | 部署 | 较复杂。 | 简单 | | 运维 | Dashboard,运维方便。 | 运维人员手动通过命令操作。 | | 监控 | 可在Dashboard里监控当前redis-server节点情况，较为便捷。 | 不提供监控功能。 | | 组织架构 | Proxy-Based, 类中心化架构，集群管理层与存储层解耦。 | P2P模型，gossip协议负责集群内部通信。去中心化 | | 伸缩性 | 支持动态伸缩。 | 支持动态伸缩 | | 主节点失效处理 | 自动选主。 | 自动选主。 | | 数据迁移 | 简单。支持透明迁移。 | 需要运维人员手动操作。支持透明迁移。 | | 升级 | 基于redis 2.8分支开发，后续升级不能保证；Redis-server必须是此版本的codis，无法使用新版本redis的增强特性。 | Redis官方推出，后续升级可保证。 | | 可靠性 | 经过线上服务验证，可靠性较高。 | 新推出，坑会比较多。遇到bug之后需要等官网升级。 |
理论上，redis-cluster的性能更高，单次请求的延时低。另外，经过实测，两种架构后端单台redis-server的条件下，TPS基本没有差别。 Codis的高可用依赖jodis，或者使用LVS进行高可用部署。
我们公司选择Codis的原因Codis简单压测单台Codis Server压测结果三台Codis-Server的集群压测结果压测结论 针对codis集群压测过程中，后端codis server平均CPU占用约为70%~80%。 单台codis的TPS在6w~7w左右，集群的TPS在17w左右，可以达到近乎线性扩展的能力 测试期间后台codis-server的负载没有跑满，仍然具有继续压测的潜力。 测试期间proxy机器负载低，可以支撑更多后端codis server实例。
使用codis注意事项
|
