Redis集群服务器-高可用调研随笔

Myth丶恋晨 2022-05-31 05:26 140阅读 0赞

转载地址：http://snowolf.iteye.com/blog/1657488

今天改了一天的Bug，本想下午开始专研Redis命令集，结果也泡汤了。只能在下班的路上考虑下Redis集群服务器的高可用方案。随笔而已，尚未成型，仅作记录。![icon_smile.gif][] 当然，我说的可能比较片面，欢迎拍砖、斧正。

# 一、Redis与MySQL对比 #

**相同点：**

*  **Master-Slave**架构，集群架构下无法很好的完成数据拷贝，确保数据一致性。
 *  支持数据文件持久化存储，但数据文件过大时，宕机重启可能存在安全隐患。

**不同点：**

*  **Redis**时效性能远比**MySQL**要高得多，支持复杂的数据类型，基本上都是内存操作，效率远胜于**MySQL。**
 *  **Redis**是**NoSQL**型数据库，或者说是**Store-Cache**型数据库，而**MySQL**属于**RDBMS**，关系型数据库，虽然自身做了查询缓存，但效果一般。
 *  **Redis**支持以数据横向切分，便于根据业务需求扩展，键值构建类似于数据库索引，灵活高效，不必忌讳数据之间的关联。**Redis**依赖其数据类型，完成交集、并集、补集计算，更胜一筹。
 *  **MySQL**在数据量和连接数量上都有上限：单表数据量**500**万条记录，并发连接数**3000**/秒。
 *  **Redis**定时、定量将数据保存至本地，命中数据大部分存活在内存中，降低了数据文件读取消耗；数据更新，以内存修改为主，不存磁盘在IO消耗。

**结论：**

*  两者在高并发环境下，依靠自身的**Master-Slave**架构，完成横向扩容都存在难度。要控制每个实例的数据文件大小，留有足够的磁盘，内存空间。确保宕机后，服务可恢复。
 *  **Redis**更适合作为频繁查询为主，对数据进行交集、补集、并集操作，类似于SNS用户社区关联关系展现等，有着良好的数据类型支持，以及高效性。

# 二、Redis与Memcached，以及EhCache/OSCache #

**EhCache**/**OSCache**、**Memcached**可谓是缓存架构里的一朵朵奇葩。

*  **EhCache**、**OSCache**在几年前，都是小应用最喜欢使用缓存实现。尤其是当应用之间不需要考虑数据一致性问题时，几乎无所不能。但到了分布式缓存时代，虽然两者也提供了相应的架构实现，但实现成本较高，且存在一定风险。例如**EhCache**，提供了**EhCache Server**架构，主要通过各个**EhCache**集群网络多播等方式同步数据。但高并发下，网络多播易演变成网络风暴。增加了系统安全隐患。
 *  **Memcached**走了另一条路，通过一致性哈希根据Key与Server的Hash对应关系，或者余数算法等，将数据散落在不同的**Server**上，确保每个**Server**上都能平均**Cache**数据。也基缘于此，**Memcached**适合进行快速地横向扩展。不必考虑磁盘存储，只需要提供一个内存足够大的**Server**主机即可。
 *  **Memcached**也有瓶颈，单个**ObjectSize**不得大于1MB，**KeySize**不得大于250个字符，**Write**要比**Read**耗时长，对大对象做**Write Cache**时尤为明显。因此，**Memcached**适合小数据量对象的**Cache**。且当服务器宕机时，疯涨的数据库操作IO，很可能将数据库服务器拖垮。

**Redis**可以简单理解为 **Store-Cache**，用作 **Cache**： **ObjectSize**支持1GB， **KeySize**支持512Bytes，并支持复杂数据类型，可在内存中直接排序等。但 **Redis**不能像 **Memcached**那样实现 **Sharding**，直接进行横向扩展。且自身作为 **Database**时，也可能存在单点故障风险。

# 三、基于Redis高可用服务器架构简单设想 #

1.  Redis以Master-Slave为单元，公用虚拟IP，通过Keepalive实现自动切换，完成主从互备。
2.  通过Redis Client，如Jedis，在Client端完成Sharding，访问多个Redis Server。
3.  读写分离，Write-Master，Read-Slave。  
    ![3f1f6ee2-e5b3-31a6-805b-15d7aae671d9.png][]  
     未尽之处，若横向扩容时，Client一致性哈希，是否会由原先的A Server指向，改为新进的C Server？单纯拷贝数据文件可解决单点到双点的实现。但多点服务器扩容，尚未做一致性哈希尝试，有一定的风险。

完全是个人头脑风暴，欢迎拍砖。 ![icon_biggrin.gif][]

[icon_smile.gif]: /images/20220531/81049772a53d4c199a27eff85f89c606.png
[3f1f6ee2-e5b3-31a6-805b-15d7aae671d9.png]: /images/20220531/c1f303fb628e486a917bc2be6ad5ad9c.png
[icon_biggrin.gif]: /images/20220531/50f41122e41a4b3abe943036e64f18e8.png