- redis服务启动配置
./redis-server ./redis.conf //启动一个redis服务找到redis-server路径加配置文件即可，可反复执行启动多个redis服务
./redis-cli -h 127.0.0.1 -p 6379 -a password //客户端连接redis服务器
redis-server服务受配置文件控制，配置文件可以控制数据持久化，集群，哨兵模式等都要在配置文件里面做出一定文章
持久化 参考文档
# requirepass foobared
requirepass 123 指定密码123
# 当在规定的时间内，Redis发生了写操作的个数满足条件，会触发发生BGSAVE命令。
# save <seconds> <changes> ,只要存在save 配置，RDB就起作用了，以下是语法介绍
# 当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次BGSAVE操作，比如：900秒之内至少一次写操作、300秒之内至少发生10次写操作、60秒之内发生至少10000次写操作都会触发发生快照操作
save 900 1
save 300 10
save 60 10000
# redis默认关闭AOF机制，可以将no改成yes实现AOF持久化
appendonly no
# AOF文件
appendfilename "appendonly.aof"
# AOF持久化同步频率，always表示每个Redis写命令都要同步fsync写入到磁盘中，但是这种方式会严重降低redis的速度；everysec表示每秒执行一次同步fsync，显示的将多个写命令同步到磁盘中；no表示让操作系统来决定应该何时进行同步fsync，Linux系统往往可能30秒才会执行一次
# appendfsync always
appendfsync everysec
# appendfsync no
# 在日志进行BGREWRITEAOF时，如果设置为yes表示新写操作不进行同步fsync，只是暂存在缓冲区里，避免造成磁盘IO操作冲突，等重写完成后在写入。redis中默认为no
no-appendfsync-on-rewrite no
# 当前AOF文件大小是上次日志重写时的AOF文件大小两倍时，发生BGREWRITEAOF操作。
auto-aof-rewrite-percentage 100
#当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF。
auto-aof-rewrite-min-size 64mb
# Redis再恢复时，忽略最后一条可能存在问题的指令(因为最后一条指令可能存在问题，比如写一半时突然断电了)
aof-load-truncated yes
#Redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，其中RDB格式的内容用于记录已有的数据，而AOF格式的内存则用于记录最近发生了变化的数据，这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）。
aof-use-rdb-preamble no
-
redis客户端与服务端交互常用命令参考:
快速展示实用命令列表展示
详情剖析每个命令空间复杂度 -
命令使用总结：redis是单线程io的，不管有多少客户端连接发过来的命令在服务器端都是一个个执行的，所以就算是多个客服端发过来的多个命令命在服务器端，也是一个一个执行的(单线程io服用，后面再研究原理),当然redis还提供了 multi 帮助我们一次性执行多个redis命令，但是它也只是帮我们保证瞬时触发muli期间准备的所有命令，并且是一次性全部执行，执行期间不会有其他客户端命令插队进来，但是并不保证其中某个命令执行失败就回滚，所以并非真的原子性，如果需要保证就需要结合lua，brpop在muli中不起作用
image.png
-
redis集群配置
阿里云服务器自带集群版本，需要注意的是集群版并非就高性能了，最多集群多少个，有些命令集群版就不支持了 -
redis哨兵模式配置
主要是服务监控，master不行了，slave就上了，哨兵模式是redis自己就支持的服务，你需要自己去配置，哨兵之间也会相互监控。 -
redis单线程io复用分析
redis真的是单线程么？答：redis各版本在处理网络请求的过程是单线程的。
分析这个问题我的可以试着从redis-cli端到redis-server全局交互着手去分析，C端通过TCP与redis服务端连接通讯从而获取相应服务的，如果不存在并发，那直接单进程单线程跑就行了啥事没有，但是并发发生后想要吞吐量优秀就需要考虑好多问题了：
- 为每个客户端分配一个线程并发跑？这种方案你需要考虑 线程开销会消耗性能，多线程一旦操作公共资源就会data race，这个代价如果太昂贵就会得不尝失，并且每个客户端一个线程你还得考虑用一个池管理资源，不然C的并发决定你线程的数目可是不行，池就又涉及到锁了，转换思路用master-work线程管理模式，注意惊群现象...于是发现解决一个问题出现好多问题。。。
- i/o多路复用？好几种实现方式（select,poll,epoll区别自行百度),epoll处理高并发优势明显，同样有需要你思考的，epoll一旦使用意味着海量并发请求服务端都是单线程一个个处理请求命令的，如果不考虑相应每个命>令redis-server相应命令的时间消耗，那么海量请求并发数目必须小于cpu的执行速度的，很明显redis笃定cpu是不会成为瓶颈的，那哪里会造成瓶颈呢？网络数据传输（tcp应答本身就存在通讯成本），redis-server后台执行耗时命令（redis纯内存以及斟酌再三的支持数据类型已表明redis已经在有意在避免耗时保证快速高效执行了，但终究还是存在O(N)级别命令的，比如说大集合，特别是数据持久化场景）
再聊redis多线程，其实多线程都是在做一些 redis-server单线程处理网络请求前的准备工作（比如说网络数据就收解密包等）和redis-server单线程处理完命令准备返回数据给客户端数据的收尾工作（返回数据给客户端业务都执行完毕了，完全没必要让单线程去等待，可以让多线程去做这部分工作，所以这里可以看出先执行的命令结果到达客户端未必有序），因为这部分工作没必要让单线程去做，分担出去自然会提高性能，向着复用那段的业务越少自然效率就越高。其实nginx与http2.0版本浏览器向服务器发送http请求都有用到i/o多路复用，有兴趣可以分别去了解下。。。
7.redis+lua实现分布式锁
参考文献
https://baijiahao.baidu.com/s?id=1644978229039981414&wfr=spider&for=pc
https://zhuanlan.zhihu.com/p/87233515
https://www.cnblogs.com/myseries/p/11733861.html
https://blog.csdn.net/tiandao321/article/details/80897160
网友评论