redis进阶1
1、redis管道
原因： redis是一种基于客户端-服务端模型，以及请求响应-协议的TCP服务。会遵循一下步骤：
客户端请求 >> 阻塞socket >> 服务端响应
问题： 如上图所示，有n次会话，其中每一次会话的时间都会依据当时网络状况而定（很快或者很慢），每次会话耗费的时间我们称之为 RTT = round trip time 往返时间。如果RTT=250ms,那么redis-server 1秒钟只能处理4个请求。
解决方案： 使用 pipelining（管道） ,一次将多个指定打包发送，服务器端收到指令后将按顺序执行。大大减少了 TTP。
重要说明: 使用管道发送命令时，服务器将被迫回复一个队列答复，占用很多内存。所以，如果你需要发送大量的命令，最好是把他们按照合理数量分批次的处理，例如10K的命令，读回复，然后再发送另一个10k的命令，等等。这样速度几乎是相同的，但是在回复这10k命令队列需要非常大量的内存用来组织返回数据内容。
来自 <http://www.redis.cn/topics/pipelining.html>
pipelining（管道的使用方法）：
1、 nc（NetCat）在网络工具中有"瑞士军刀"的美誉，其有Windows和Linux的版本。因为它短小精悍（1.84版本也不过25k，旧版本或缩减版甚至更小）、功能实用，被设计为一个简单、可靠的网络工具，可通过TCP或UDP协议传输读写数据。同时，它还是一个网络应用Debug分析器，因为它可以根据需要创建各种不同类型的网络连接。
通过nc发送请求有2种
a、先打通管道，再发送命令（可能会出现键位错乱）。
b、将命令直接发送到管道。
命令格式为：
Echo -e "redis命令以\n分割" | nc ip port
2、发布订阅（可以作为直播评论区）
a、安照下列执行顺序可得出一结论，什么时候开始监听，什么时候就可以获取监听之后的消息。
拓展：
在一个直播平台中，用户需要查看实时评论，有需要查看3天以内的历史评论，还需要查看更久之前的评论。redis是如何解决？？？如下细节图
流程图：
3、事务
***只有同时具备MULTI 和 EXEC 才会执行。如果有多个事务同时开启，哪个事务最先提交谁的命令就最先执行。
MULTI ：开启事务
EXEC : 提交事务
DISCARD : 取消事务
WATCH：这是一个很好用的指令，它可以帮我们实现类似于"乐观锁"的效果，即CAS（check and set）。
WATCH本身的作用是"监视key是否被改动过"，而且支持同时监视多个key，只要还没真正触发事务，WATCH都会尽职尽责的监视，一旦发现某个key被修改了，在执行EXEC时就会返回nil，表示事务无法触发。
4、模块、过滤器（防止mysql被击穿）
在根目录下新建redisBloom文件夹，并进入执行命令：
wget https://github.com/RedisBloom/RedisBloom/archive/master.zip
解压后，进入文件夹，按照Readme提示，直接执行 make 。执行完毕后目录文件会生成一个redisBloom.so的文件。
将文件复制到 /opt/bigdata/redis5/ 下 与redis的bin目录同一级别。
然后 停止redis服务：
Service redis_port stop
查看服务：
Service redis_port status
最后挂载Bloom模块启动
Redis-server /etc/redis/6379.conf --loadmodule /opt/bigdata/redis5/redisBloom.so(此处一定要是绝对路径)。
Bloom过滤器
添加元素的原理
- 将要添加的元素给k个hash函数
- 得到对应于位数组上的k个位置
- 将这k个位置设置成 1
查询元素原理
- 将要查询的元素给k个hash函数
- 得到对应数组的k个元素
- 如果k个位置中有一个为0,则肯定不在集合中
- 如果k个位置全部为1,则有可能在集合中
5、数据库/缓存
5、缓存
redis缓存的消亡，内存过期的问题？？？
