redis学习摘要
一、redis部署
二、订阅发布
1.redis自身的订阅发布
Redis从2.X版本开始，就支持一种基于非持久化消息的、使用发布/订阅模式实现的事件通知机制。客户端离线重连后，离线期间的事件无法被重新通知，
10.15.107.145:7000> PUBLISH channeltestsub testmessage
(integer) 1
10.15.107.145:7000>
10.15.107.145:7000> SUBSCRIBE channeltestsub
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channeltestsub"
3) (integer) 1
1) "message"
2) "channeltestsub"
3) "testmessage"
2.云平台对存储中key的订阅
除了redis的订阅发布功能外，再封装一层代理，总线等基础框架来完成。可能是综合考虑到了负载均衡和路由。
三、影响redis性能的因素
网络带宽和延迟通常是最大短板。
查看本地网卡带宽
[root@localhost ~]# ifconfig em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.15.107.179 netmask 255.255.255.0 broadcast 10.15.107.255 ... [root@localhost ~]# sudo ethtool em1 Settings for em1: ... Speed: 1000Mb/s ...以上命令查看到本地网卡是千兆的“1000Mb/s”。
使用 ping 来粗略计算网络带宽
[root@localhost ~]# ping 10.15.107.115 PATTERN: 0x190000 PING 10.15.107.115 (10.15.107.115) 56(84) bytes of data. 64 bytes from 10.15.107.115: icmp_seq=1 ttl=64 time=0.625 ms ^C --- 10.15.107.115 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.625/0.625/0.625/0.000 ms以上命令得知： 网速大概为64/0.625 bytes/ms = 102Mbps，同理用极限命令“ ping -f -s 65507 10.15.107.115”,测算出网速最大大概在 65506/9.919 = 6604Mbps
应用： 比如将 4 KB 的字符串塞入 Redis，吞吐量是 100000 q/s，那么实际需要 3.2 Gbits/s 的带宽，所以需要 10 Gbits/s 网络连接， 1 Gbits/s 是不够的
CPU 是另外一个重要的影响因素，由于是单线程模型，Redis 更喜欢大缓存快速 CPU， 而不是多核。
推荐Intel CPU。据网络数据显示，AMD CPU可能只有 Intel CPU 的一半性能- 在小对象存取时候，内存速度和带宽看上去不是很重要，但是对大对象（> 10 KB）， 它就变得重要起来。不过通常情况下面，倒不至于为了优化 Redis 而购买更高性能的内存模块。
- Redis 在 VM 上会变慢。配置相当的虚拟机上redis-benchmark的测试结果比物理机器上慢了一倍，很多 CPU 时间被消费在系统调用和中断上面。
当使用网络连接时，并且以太网网数据包在 1500 bytes 以下时,将多条命令包装成pipelining可以大大提高效率。事实上，处理10 bytes100 bytes，1000 bytes的请求时候，吞吐量是差不多的.减少网络延迟
实验机器CPU:Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz
实验机器redis_version:3.2.4
实验机器mem_allocator:libc
（with pipelining）[root@localhost ~]# redis-benchmark -h 10.15.107.115 -p 19000 -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q
SET: 17140.46 requests per second
GET: 20809.71 requests per second
LPUSH: 17288.33 requests per second
LPOP: 14601.31 requests per second
（without pipelining）[root@localhost ~]# redis-benchmark -h 10.15.107.115 -p 19000 -r 1000000 -n 2000000 -t get,set,lpush,lpop -q
SET: 2426.79 requests per second
GET: 2121.18 requests per second
LPUSH: 3136.17 requests per second
LPOP: 3134.62 requests per second通过网络读写redis的时，批量(Batch)操作有益于大批提高性能，因为Redis本身就是基于tcp的一个Request/Response protocol模式，所以，可以使用wireshark抓包分析redis读写过程。
- 在高配置下面，客户端的连接数也是一个重要的因素。得益于 epoll/kqueue， Redis 的事件循环具有相当可扩展性。Redis 已经在超过 60000 连接下面基准测试过， 仍然可以维持50000q/s。一条经验法则是，30000 的连接数只有 100 连接的一半吞吐量
- 在不同平台下面，Redis 可以被编译成不同的内存分配方式（libc malloc, jemalloc, tcmalloc），他们在不同速度、连续和非连续片段下会有不一样的表现。 如果你不是自己编译的 Redis，可以使用 INFO 命令来检查内存分配方式。 请注意，大部分基准测试不会长时间运行来感知不同分配模式下面的差异， 只能通过生产环境下面的 Redis 实例来查看。不同内存分配方式的对比http://blog.youkuaiyun.com/yongche_shi/article/details/54614144
四、redis的持久化操作
通过info命令查看Persistence
[root@localhost ~]# redis-cli -h 10.15.107.145 -p 7000
10.15.107.145:7000> info Persistence
# Persistence
loading:0 #服务器是否正在载入持久化文件
rdb_changes_since_last_save:0 #离最近一次成功生成rdb文件，写入命令的个数，即有多少个写入命令没有持久化
rdb_bgsave_in_progress:0 #服务器是否正在创建rdb文件
rdb_last_save_time:1510218400 #离最近一次成功创建rdb文件的时间戳。当前时间戳-rdb_last_save_time=多少秒未成功生成rdb文件
rdb_last_bgsave_status:ok #最近一次rdb持久化是否成功
rdb_last_bgsave_time_sec:1 #最近一次成功生成rdb文件耗时秒数
rdb_current_bgsave_time_sec:-1 #如果服务器正在创建rdb文件，那么这个域记录的就是当前的创建操作已经耗费的秒数
aof_enabled:0 #是否开启了aof
aof_rewrite_in_progress:0 #标识aof的rewrite操作是否在进行中
aof_rewrite_scheduled:0 #rewrite任务计划，当客户端发送bgrewriteaof指令，如果当前rewrite子进程正在执行，那么将客户端请求的bgrewriteaof变为计划任务，待aof子进程结束后执行rewrite
aof_last_rewrite_time_sec:-1 #最近一次aof rewrite耗费的时长
aof_current_rewrite_time_sec:-1 #如果rewrite操作正在进行，则记录所使用的时间，单位秒
aof_last_bgrewrite_status:ok #上次bgrewriteaof操作的状态
aof_last_write_status:ok #上次aof写入状态
自己踩的坑：
因为内网测试环境redis集群没有配置持久化，在某次断电后导致部分数据丢失。
别人踩的坑：内存飙升，由于输出缓冲区大量数据堵塞
扫一扫
5619
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
