Redis 安装和集群方案

àì夳堔傛蜴生んèń 2022-03-08 05:36 259阅读 0赞

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。 Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。 1． 下载地址： $ wget <a href="http://redis.googlecode.com/files/redis-2.6.13.tar.gz" rel="nofollow">http://redis.googlecode.com/files/redis-2.6.13.tar.gz</a> 2． 解压缩 $ tar xzf redis-2.6.13.tar.gz 3． 编译 $ cd redis-2.6.13&nbsp; $yum install gcc &nbsp;(视情况而定，如果没有安装gcc就可以安装，查看是否安装命令 rpm -qa | grep -i gcc) $ make $make install $cp redis.conf /etc/ 参数介绍： make install命令执行完成后，会在/usr/local/bin目录下生成本个可执行文件，分别是redis-server、redis-cli、redis-benchmark、redis-check-aof 、redis-check-dump，它们的作用如下： redis-server：Redis服务器的daemon启动程序 redis-cli：Redis命令行操作工具。也可以用telnet根据其纯文本协议来操作 redis-benchmark：Redis性能测试工具，测试Redis在当前系统下的读写性能 redis-check-aof：数据修复 redis-check-dump：检查导出工具 4． 修改系统配置文件，执行命令 a) echo vm.overcommit_memory=1 &gt;&gt; /etc/sysctl.conf b) sysctl vm.overcommit_memory=1 或执行echo vm.overcommit_memory=1 &gt;&gt;/proc/sys/vm/overcommit_memory 使用数字含义： 0，表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。 1，表示内核允许分配所有的物理内存，而不管当前的内存状态如何。 2，表示内核允许分配超过所有物理内存和交换空间总和的内存 5． 修改redis配置文件 a) $ cd /etc b) vi redis.conf c) 修改daemonize yes---目的使进程在后台运行 参数介绍： daemonize：是否以后台daemon方式运行 pidfile：pid文件位置 port：监听的端口号 timeout：请求超时时间 loglevel：log信息级别 logfile：log文件位置 databases：开启数据库的数量 save * *：保存快照的频率，第一个*表示多长时间，第三个*表示执行多少次写操作。在一定时间内执行一定数量的写操作时，自动保存快照。可设置多个条件。 rdbcompression：是否使用压缩 dbfilename：数据快照文件名（只是文件名，不包括目录） dir：数据快照的保存目录（这个是目录） appendonly：是否开启appendonlylog，开启的话每次写操作会记一条log，这会提高数据抗风险能力，但影响效率。 appendfsync：appendonlylog如何同步到磁盘（三个选项，分别是每次写都强制调用fsync、每秒启用一次fsync、不调用fsync等待系统自己同步） 6． 启动redis a) $ cd /usr/local/bin b) ./redis-server /etc/redis.conf 7． 检查是否启动成功 a) $ ps -ef | grep redis -------------------------------------------------------------------------------安装结束---------------------------------------------------------------------------------- 根据一些测试整理出来的一份方案： <h1>1. Redis 性能</h1> 
 <blockquote> 
 对于redis 的一些简单测试，仅供参考： 
 测试环境：Redhat6.2 , Xeon E5520(4核)*2/8G，1000M网卡 
 Redis 版本：2.6.9 
 &nbsp; 
 客户端机器使用redis-benchmark 简单GET、SET操作： 
 <h2>1. 1单实例测试</h2> 
 1. Value大小：10Byte~1390Byte 
 处理速度： 7.5 w/s，速度受单线程处理能力限制 
 2. Value 大小：1400 左右 
 处理速度突降到5w/s 样子，网卡未能跑满；由于请求包大于MTU造成TCP分包，服务端中断处理请求加倍，造成业务急剧下降。 
 3. Value大小：&gt;1.5 k 
 1000M网卡跑满，速度受网卡速度限制 
 </blockquote> 
 <blockquote> 
 处理速度与包大小大概关系如下： 
 <a href="http://images.cnitblog.com/blog/28886/201306/10164145-a7d6055272894bcc8e893a5eb977ade2.png" rel="nofollow"><img alt="image" height="248" src="http://images.cnitblog.com/blog/28886/201306/10164146-f544bd50d4934946ba8bb80bdf9a9406.png?pt=5&amp;ek=1&amp;kp=1&amp;sce=0-12-12" width="352"></a> 
 <h2>1.2 多实例测试</h2> 
 前提是系统网卡软中断均衡到多CPU核心处理，测试机器网卡开启RSS，有16个队列： 
 操作：10字节Value SET，服务端开启8个实例，四台客户端服务器每台开启两个redis-benchmark，每个client 速度近4W/s，服务端总处理30w/s左右。 
 网卡流量： 
 <a href="http://images.cnitblog.com/blog/28886/201306/10164147-0e10d68fadf744a8a8b70b7f97c22ad6.png" rel="nofollow"><img alt="image" height="56" src="http://images.cnitblog.com/blog/28886/201306/10164148-5bdac6a03a6c414490810a44bad16e1d.png?pt=5&amp;ek=1&amp;kp=1&amp;sce=0-12-12" width="522"></a> 
 其中8个单数核心CPU全部耗尽，像是超线程没有利用上，测试已经达到很好效果，就没有继续测试下去了。从单实例跑满一个核心7.5w/s，8个实例跑满8个核心，30W/s来看，CPU使用和性能提升不成正比， RSS会造成redis-server线程基本每收到一个请求都切换一次CPU核心，软中断CPU占用太高。这种情况RPS/RFS功能也许就很合适了，RSS只需要映射1~2个核心，然后再讲软中断根据redis-server端口动态转发，保证redis进程都在一个核心上执行，减少进程不必要的切换。 
 &nbsp; 
 开多实例可以充分利用系统CPU、网卡处理小包能力。具体看业务场景，考虑包平均大小、处理CPU消耗、业务量。如果多实例是为了提高处理能力，需要注意配置网卡软中断均衡，否则处理能力也无法提升。 
 </blockquote> <h1>&nbsp;</h1> <h1>2. Redis 持久化</h1> 
 <blockquote> 
 测试策略：AOF + 定时rewriteaof 
 1. 准备数据量： 
 1亿，Key：12 字节 Value：15字节，存储为string，进程占用内存12G 
 2. Dump 
 文件大小2.8G，执行时间：95s，重启加载时间：112s 
 2. Bgrewriteaof 
 文件大小5.1G，执行时间：95s，重启加载时间：165s 
 3.开启AOF后性能影响（每秒fsync一次）： 
 8K/s SET 操作时：cup 从20% 增加到40% 
 4.修改1Kw数据： 
 文件大小：5.6G，<a rel="nofollow"></a><a rel="nofollow"></a>重启加载时间：194s 
 5.修改2K数据 
 文件大小：6.1G，重启加载时间：200s 
 另：Redis2.4 版本以后对fsync做了不少优化， bgrewriteaof，bgsave 期间对redis对外提供服务完全无任何影响。 
 </blockquote> <h1>&nbsp;</h1> <h1>3. Redis 主从复制</h1> 
 <blockquote> 
 因为目前版本没有mysql 主从那样的增量备份，对网路稳定性要求很高，如果频繁TCP连接断开会对服务器和网络带来很大负担。 
 就目前生产环境主从机器部署同一个机架下，几个月都不会又一次连接断开重连的情况的。 
 </blockquote> <h1>&nbsp;</h1> <h1>4. keepalived 简介</h1> 
 <blockquote> 
 参考官方文档：<a href="http://keepalived.org/pdf/sery-lvs-cluster.pdf" rel="nofollow">http://keepalived.org/pdf/sery-lvs-cluster.pdf</a> 
 Keepalived 是一个用c写的路由选择软件，配合IPVS 负载均衡实用，通过VRRP 协议提供高可用。目前最新版本1.2.7.Keepalived 机器之间实用VRRP路由协议切换VIP，切换速度秒级，且不存在脑裂问题。可以实现 
 可以实现一主多备，主挂后备自动选举，漂移VIP，切换速度秒级；切换时可通过运行指定脚本更改业务服务状态。 
 如两台主机A、B，可以实现如下切换： 
 1．A 、B 依次启动，A作为主、B为从 
 2 .主A 挂掉，B接管业务，作为主 
 3.A 起来，作为从SLAVEOF B 
 4.B 挂掉，A 切回主 
 将一台全部作为主，即可实现主从，可做读写分离；也可以通过多个VIP，在一台机器上多个实例中一半主、一半从，实现互备份，两机同时负责部分业务，一台宕机后业务都集中在一台上 
 安装配置都比较简单： 
 　　需要依赖包：openssl-devel（ubuntu 中为 libssl-dev),popt-devel （ubuntu中为libpopt-dev）。 
 　　配置文件默认路径：/etc/keepalived/keepalived.conf 也可以手动指定路径，不过要注意的是手动指定需要使用绝对路径。主要要确保配置文件的正确性，keepalived 不会检查配置是否符合规则。 
 　　使用keepalived -D 运行，即可启动3个守护进程：一个父进程，一个check健康检查，一个Vrrp，-D将日志写入/var/log/message，可以通过日志查看切换状况。 
 </blockquote> 
 <blockquote> 
 注意问题： 
 1. VRRP 协议是组播协议，需要保证主、备、VIP 都在同一个VLAN下 
 2. 不同的VIP 需要与不同的VRID 对应，一个VLAN 中VRID 不能和其他组冲突 
 3. 在keepalived 有两个角色：Master(一个)、Backup（多个），如果设置一个为Master，但Master挂了后再起来，必然再次业务又一次切换，这对于有状态服务是不可接受的。解决方案就是两台机器都设置为Backup，而且优先级高的Backup设置为nopreemt 不抢占。 
 </blockquote> <h1>&nbsp;</h1> <h1>5. 通过keepalived实现的高可用方案</h1> 
 <blockquote> 
 &nbsp; 
 <a href="http://images.cnitblog.com/blog/28886/201306/10164149-517070bfdd8c4ecc832d3ad4e581f87c.png" rel="nofollow"><img alt="image" height="363" src="http://images.cnitblog.com/blog/28886/201306/10164150-983fdb63f1f34b81947f384e4d819d35.png?pt=5&amp;ek=1&amp;kp=1&amp;sce=0-12-12" width="582"></a> 
 切换流程： 
 1. 当Master挂了后，VIP漂移到Slave；Slave 上keepalived 通知redis 执行：slaveof no one ,开始提供业务 
 2. 当Master起来后，VIP 地址不变，Master的keepalived 通知redis 执行slaveof slave IP host ，开始作为从同步数据 
 3. 依次类推 
 主从同时Down机情况： 
 1. 非计划性，不做考虑，一般也不会存在这种问题 
 2. 、计划性重启，重启之前通过运维手段SAVE DUMP 主库数据；需要注意顺序： 
 1. 关闭其中一台机器上所有redis，是得master全部切到另外一台机器（多实例部署，单机上既有主又有从的情况）；并关闭机器 
 2. 依次dump主上redis服务 
 3. 关闭主 
 4. 启动主，并等待数据load完毕 
 5. 启动从 
 删除DUMP 文件（避免重启加载慢） 
 </blockquote> &nbsp; <h1>6. 使用Twemproxy 实现集群方案</h1> 
 <blockquote> 
 一个由twitter开源的c版本proxy，同时支持memcached和redis，目前最新版本为：0.2.4，持续开发中;<a href="https://github.com/twitter/twemproxy" rel="nofollow">https://github.com/twitter/twemproxy</a> .twitter用它主要减少前端与缓存服务间网络连接数。 
 特点：快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash 分片算法。 
 <a href="http://images.cnitblog.com/blog/28886/201306/10164151-f420e31e69844d859c32ea204976cb84.png" rel="nofollow"><img alt="image" height="383" src="http://images.cnitblog.com/blog/28886/201306/10164153-10d5562feeb5478cb0dd3df29293937e.png?pt=5&amp;ek=1&amp;kp=1&amp;sce=0-12-12" width="609"></a> 
 这里使用keepalived实现高可用主备方案，解决proxy单点问题； 
 优点： 
 1. 对于客户端而言，redis集群是透明的，客户端简单，遍于动态扩容 
 2. Proxy为单点、处理一致性hash时，集群节点可用性检测不存在脑裂问题 
 3. 高性能，CPU密集型，而redis节点集群多CPU资源冗余，可部署在redis节点集群上，不需要额外设备 
 </blockquote> &nbsp; <h1>7 . 一致性hash</h1> 
 <blockquote> 
 使用zookeeper 实现一致性hash。 
 redis服务启动时，将自己的路由信息通过临时节点方式写入zk，客户端通过zk client读取可用的路由信息。 
 具体实现见我另外一篇：<a href="http://www.cnblogs.com/lulu/archive/2013/06/10/3130906.html" rel="nofollow">redis 一致性hash</a> 
 </blockquote> <h1>8 . 监控工具</h1> 
 <blockquote> 
 历史redis运行查询：CPU、内存、命中率、请求量、主从切换等 
 实时监控曲线 
 短信报警 
 使用基于开源Redis Live 修改工具，便于批量实例监控，基础功能都已实现，细节也将逐步完善。 
 源码地址如下: 
 <a href="https://github.com/LittlePeng/redis-monitor" rel="nofollow">https://github.com/LittlePeng/redis-monitor</a> 
 <a href="https://github.com/LittlePeng/redis-monitor" rel="nofollow">转载博客园 LittlePeng</a> 
 </blockquote> </td> 
 </tr> 
 </tbody> 
</table>