redis简单的优化

1.慢查询

总所周知，一次连接redis操作分为四步：
网络发送 --redis队列–redis操作–网络返回

慢查询就是监控 第三步redis操作的
redis中的慢查询功能将 比较慢的操作维护在一个列表当中

至于操作多久算慢呢，这个你说的算：
slowlog-log-slower-than 自定义慢查询的阈值单位是微秒
（冷知识 1秒 =1000毫秒 = 1000 000 微秒）
slowlog-max-len 定义这个队列大小

通过 slowlog get n（条数） 可以查看慢查询的日志

值得注意的一点，如果慢查询的 队列爆仓了。那么队列策略是丢弃最早入队的慢查询，因此最好将slowlog-max-len设置大点，以免每次分析时丢失一些慢查询记录了

2.pipleline

慢查询可以监控redis操作，以此做出优化，那么网络发送和网络可以优化吗，毕竟不是都说redis的瓶颈在网路吗。

这时就要说pipleline了，pipleline可以将多个操作请求打包起来一起发给redis，类似于批操作，
将原本n次的的网络通信，压缩成1次，以此减少通信的成本

这时候我就想，既然可以通过pipleline可以减少网络通信成本，那我直接攒波大的一次发过去，那不是可以省很多事

网络带宽听了表示很淦。。
首先 一个TCP包的大小是 1460字节
如果超过这个数，就会出现分包，半包，粘包的情况
如果要求redis原子性比较高的情况下，多包的情况可能会影响到原子性
其次 过大的pipleline会造成网络阻塞，增加单次客户端的响应时间

所以还是建议一次pipleline在1460字节内

3.redis事务

有时我们需要多条命令一起执行，要么一起不执行，这段话是不是很耳熟，没错，该redis事务出场了

multi：开始事务
exec：结束事务
discard 都不执行

在事务当中，执行完一条命令后，redis会返回queued，表示这时的命令存在队列中， 在执行到exec后，一次性提交

这是有朋友就问了如果事务出现了错误会怎样
这时就分两种情况啦

第一种，命令错误

比如这个笔者手残输错了exec，结果就导致了整个事务都提交失败了

第二种，运行是错误

事务能够正确的执行结束，只有出错的不予执行

至于说回滚，redis没有redo日志，也没有undo日志，所以做不到回滚的啦

4.watch
上文当中说的pipleline多包会引起原子性问题
watch 操作类似于 cas 操作

原理是通过watch 命令 监控某个key 如果事务结束后该key发生变化 则不执行（事务的全部内容都不执行）

ps： watch 结束后记得unwatch 。