ke1ying的博客

当我们并发量很高，或者并发量很频繁的时候，maxIdle和maxTotal设置可以保持一致，这样避免连接创建和关闭造成的性能损耗，并发量不是特别高就没必要。因为如果每个客户端处理的是1000，而我们有10个客户端，那么可以处理10000，即使maxclients设计的再大，剩余的也不会存储。前者是非原生的，后者是原生的，原生有原子性，非原生没有，pipeline可以打包不同命令，并且他需要客户端服务端都支持。对于主从节点，主节点是策略删除，从节点是被同步的del key删除。

Redis集群过半机制会有脑裂问题，导致多个master对外提供服务，一旦网络分区恢复正常，会有大量数据丢失。这样的话算哈希值就只用user1，防止keying和age落在不同的槽位，如果落在不同槽位，其中一个槽位宕机，则set失败。5s超时时间，这个不能设置太小，太小的话，直接选举新的master，导致多个master，防止网络抖动连接异常而导致问题。（这个尽量少用，根据场景来，作为缓存，少量丢失数据并没有影响，但是如果slave宕机而导致不可以才是不允许的）

高可用集群架构，与前面的哨兵最大区别是，这边会分片放，前面哨兵如果master放10个g，那么这里的cluster则会分成三部分，分别为3个g，3个g，4个g。因为如果配置rdb或者重写的时候，内存特别大的时候，会给主节点造成非常大的压力，所以要小于10个G。但redis本身由哨兵，我们可以通过配置哨兵来监听主节点是否宕机，宕机发起选举新的主节点。主从的搭建我们已经完成，但如果主节点宕机，这时候导致整个redis服务不可用怎么办呢？运维可以手动重启主节点，或者手动去修改从节点，把从节点改为主节点。

Script里有一个KEYS[1]和ARGV[1]，这两个值分别对应着下面代码eval的两个参数，所以a的值获取为15，b的值获取为10.6379redis写入数据，在6380里是可以看到的，并且因为配置了只读，所以我在6380redis里操作set命令不能成功。这里则不能再lua脚本出现死循环和耗时运算，因为他是单线程，如果因为lua脚本耗时太长甚至死循环，则整个redis会阻塞。如果slave挂了几分钟，这时候不需要同步全量数据，只需要复制新增的master数据。

子线程是由主线程fork产生的，完全共享主线程的数据，主线程read则不传递给子线程，当write时候，就会和子线程共享。Auto-aof-rewrite-min-size 64mb：意思是当aof文件有64mb的时候，就会清理上面那些垃圾命令。2、当在aof重写的时候，不会再把优化写成一条一条命令，而是写成二进制的rdb格式，存入aof文件。后面要恢复数据的时候，二进制直接在电脑显示，效率更高，存储的格式也更紧凑。（没开启混合的时候，aof存的是数据，打开之后，存的是二进制rdb格式）

这样好处就是可以代替数据库来做这些操作，最后在提交的时候持久化到数据库，提高使用效率，提升用户体验感。（数据库做复杂，并且性能低）当前命令也可以在分布式数据库的情况下，来作为id使用，但每次获取都用这个执行一次非常耗费性能，所以可以一次性批量生成。用法是在每个服务器取一次，一次取1000个号，在单机内存中使用，使用完再取一次，减少与redis交互。相信大家都存过，我们一般都是把对象value转json，获取的时候，再json转对象。当我们需要文章点击量时候，我们可以执行这个，执行一次代表一次点击量，

key 0 5，则可以实际作用于微信公众号和微博推送，按顺序推送前五个发消息给你的文章显示出来，这种redis实现比数据库实现效率高很多。解析：BLPOP从列表的左边弹出一个元素，若列表没有元素，阻塞等待timeout秒，右边弹出一个从列表的右边弹出一个元素，若列表没有元素，阻塞等待timeout秒，Set会自动去重，比如抽奖的情况下，防止用户重复抽奖，如图可以看到，李四。差集怎么理解的，是第一个集合减去后面两个集合的并集。