This paper mainly deals Redis several common use to analyze their advantages and disadvantages.
First, the common usage
Redis several common use include:
-
Redis single copy;
-
Redis multiple copies (master-slave);
-
Redis Sentinel (Sentinel);
-
Redis Cluster；
-
Redis self-study.
Second, the use of the advantages and disadvantages
1, Redis single copy
Redis single copy, Redis using a single node deployment architecture, there is no real-time synchronization of data backup node, do not provide data persistence and backup strategy for data reliability of less demanding cache pure business scenarios.
advantage:
-
Simple structure, easy to deploy;
-
Cost-effective: no spare node cache use (single instance or supervisor can use crontab availability guarantee), of course, in order to meet the high availability of business you can also sacrifice a spare node, but at the same time there is only one instance of external services;
-
high performance.
Disadvantages:
-
It does not guarantee the reliability of the data;
-
Use the cache, restart the process after the data is lost, even if there is a spare node address high availability, but still can not solve the problem of cache warming, and therefore not suitable for high data reliability requirements of the business;
-
High performance is limited by the processing capability of a single-core CPU (the Redis is single threaded mechanism), the main CPU bottleneck, so for simple operation command, ordering, less computation scene. You may also consider an alternative use Memcached.
2, Redis multiple copies (master-slave)
Redis multiple copies, using the master deployment from (replication) structure, compared to the single copy of the terms of the biggest feature is the master synchronization between instances from real-time data and provides data persistence and backup strategy. Master-slave instances deployed on separate physical servers, according to the company's foundation environment configuration can be achieved at the same time provide services and separate read and write policies.
advantage:
-
High Reliability: In one aspect, the use of dual-standby architecture can be performed when the primary database fails automatic switchover, from the library to a primary library provides services to ensure smooth operation of the service; on the other hand, data persistence feature is turned on and configure a reasonable backup strategy, can effectively solve the abnormal data misuse and data loss problem;
-
Separate read and write strategies: the ability to read from a node can expand the master database node, to effectively deal with a large amount of concurrent reads.
Disadvantages:
-
故障恢复复杂，如果没有RedisHA系统（需要开发），当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其它从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐；
-
主库的写能力受到单机的限制，可以考虑分片；
-
主库的存储能力受到单机的限制，可以考虑Pika；
-
原生复制的弊端在早期的版本中也会比较突出，如：Redis复制中断后，Slave会发起psync，此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿；又由于COW机制，导致极端情况下的主库内存溢出，程序异常退出或宕机；主库节点生成备份文件导致服务器磁盘IO和CPU（压缩）资源消耗；发送数GB大小的备份文件导致服务器出口带宽暴增，阻塞请求，建议升级到最新版本。
3、Redis Sentinel（哨兵）
Redis Sentinel是社区版本推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群。
其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1（n>=1）的奇数个。
优点：
-
Redis Sentinel集群部署简单；
-
能够解决Redis主从模式下的高可用切换问题；
-
很方便实现Redis数据节点的线形扩展，轻松突破Redis自身单线程瓶颈，可极大满足Redis大容量或高性能的业务需求；
-
可以实现一套Sentinel监控一组Redis数据节点或多组数据节点。
缺点：
-
部署相对Redis主从模式要复杂一些，原理理解更繁琐；
-
资源浪费，Redis数据节点中slave节点作为备份节点不提供服务；
-
Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换，对Redis的数据节点做失败判定分为主观下线和客观下线两种，对于Redis的从节点有对节点做主观下线操作，并不执行故障转移。
-
不能解决读写分离问题，实现起来相对复杂。
建议：
-
如果监控同一业务，可以选择一套Sentinel集群监控多组Redis数据节点的方案，反之选择一套Sentinel监控一组Redis数据节点的方案。
-
sentinel monitor <master-name> <ip> <port> <quorum> 配置中的<quorum>建议设置成Sentinel节点的一半加1，当Sentinel部署在多个IDC的时候，单个IDC部署的Sentinel数量不建议超过（Sentinel数量 – quorum）。
-
合理设置参数，防止误切，控制切换灵敏度控制：
a. quorum
b. down-after-milliseconds 30000
c. failover-timeout 180000
d. maxclient
e. timeout
-
部署的各个节点服务器时间尽量要同步，否则日志的时序性会混乱。
-
Redis建议使用pipeline和multi-keys操作，减少RTT次数，提高请求效率。
-
自行搞定配置中心（zookeeper），方便客户端对实例的链接访问。
4、Redis Cluster
Redis Cluster是社区版推出的Redis分布式集群解决方案，主要解决Redis分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster能起到很好的负载均衡的目的。
Redis Cluster集群节点最小配置6个节点以上（3主3从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。
Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0～16383个整数槽内，每个节点负责维护一部分槽以及槽所印映射的键值数据。
优点：
-
无中心架构；
-
数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布；
-
可扩展性：可线性扩展到1000多个节点，节点可动态添加或删除；
-
高可用性：部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升；
-
降低运维成本，提高系统的扩展性和可用性。
缺点：
-
Client实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
-
节点会因为某些原因发生阻塞（阻塞时间大于clutser-node-timeout），被判断下线，这种failover是没有必要的。
-
数据通过异步复制，不保证数据的强一致性。
-
多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。
-
Slave在集群中充当“冷备”，不能缓解读压力，当然可以通过SDK的合理设计来提高Slave资源的利用率。
-
Key批量操作限制，如使用mset、mget目前只支持具有相同slot值的Key执行批量操作。对于映射为不同slot值的Key由于Keys不支持跨slot查询，所以执行mset、mget、sunion等操作支持不友好。
-
Key事务操作支持有限，只支持多key在同一节点上的事务操作，当多个Key分布于不同的节点上时无法使用事务功能。
-
Key作为数据分区的最小粒度，不能将一个很大的键值对象如hash、list等映射到不同的节点。
-
不支持多数据库空间，单机下的redis可以支持到16个数据库，集群模式下只能使用1个数据库空间，即db 0。
-
复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
-
避免产生hot-key，导致主库节点成为系统的短板。
-
避免产生big-key，导致网卡撑爆、慢查询等。
-
重试时间应该大于cluster-node-time时间。
-
Redis Cluster不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。
5、Redis自研
Redis自研的高可用解决方案，主要体现在配置中心、故障探测和failover的处理机制上，通常需要根据企业业务的实际线上环境来定制化。
优点：
-
高可靠性、高可用性；
-
自主可控性高；
-
贴切业务实际需求，可缩性好，兼容性好。
缺点：
-
实现复杂，开发成本高；
-
需要建立配套的周边设施，如监控，域名服务，存储元数据信息的数据库等；
-
维护成本高。
转载：https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650769962&idx=1&sn=b5f17dc7dd92da78b61c714b2bb422c0&chksm=f3f93fbfc48eb6a95cd7fcffb79fe1b7b83d5a340f2927109997519ca84a64f020f5d217d979&mpshare=1&scene=1&srcid=0820pLsFfQAg7oLhGpKa70zR&sharer_sharetime=1577245430100&sharer_shareid=2c37efa019a178d71e8c98827544bb6f&key=b7a7dc989522e12acafce7d3bacc3991f75a5ede617ac43fa6082523d3c1cb3f566c8afc78f0fa9a213b52610d8ceaebbd36f249153ceb616410c59f226ae29c08c1b521dc90313ddea995f4f9d7223d&ascene=1&uin=MTIyMjYwNDM4MA%3D%3D&devicetype=Windows+10&version=6207024c&lang=zh_CN&exportkey=AQzVve3a87V%2BZoJ8xaQOmK4%3D&pass_ticket=nPX4uDAmNt%2BBnXE9SLGpoetg2E2s0FqtTQ%2BohcfLMqOFfo4g69qeyonFGd3g1Eg4