今天改了一天的Bug,本想下午开始专研Redis命令集,结果也泡汤了。只能在下班的路上考虑下Redis集群服务器的高可用方案。随笔而已,尚未成型,仅作记录。 当然,我说的可能比较片面,欢迎拍砖、斧正。
一、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高可用服务器架构简单设想
- Redis以Master-Slave为单元,公用虚拟IP,通过Keepalive实现自动切换,完成主从互备。
- 通过Redis Client,如Jedis,在Client端完成Sharding,访问多个Redis Server。
- 读写分离,Write-Master,Read-Slave。
未尽之处,若横向扩容时,Client一致性哈希,是否会由原先的A Server指向,改为新进的C Server?单纯拷贝数据文件可解决单点到双点的实现。但多点服务器扩容,尚未做一致性哈希尝试,有一定的风险。
时间: 2024-10-12 07:44:59