1、redis能否代替etcd或者zookeeper
源自https://www.v2ex.com/t/520367 #3 @xkeyideal
简单从以下几个方面说一下redis为啥在微服务中不能取代 etcd：
- redis 没有版本的概念，历史版本数据在大规模微服务中非常有必要，对于状态回滚和故障排查，甚至定锅都很重要
- redis 的注册和发现目前只能通过 pub 和 sub 来实现，这两个命令完全不能满足生产环境的要求，具体原因可以 gg 或看源码实现
- etcd 在 2.+版本时，watch 到数据官方文档均建议再 get 一次，因为会存在数据延迟，3.+版本不再需要，可想 redis 的 pub 和 sub 能否达到此种低延迟的要求
- 楼主看到的微服务架构应该都是将 etcd 直接暴露给 client 和 server 的，etcd 的性能摆在那，能够承受多少的 c/s 直连呢，更好的做法应该是对 etcd 做一层保护，当然这种做法会损失一些功能
- redis 和 etcd 的集群实现方案是不一致的，etcd 采用的是 raft 协议，一主多从，只能写主，底层采用 boltdb 作为 k/v 存储，直接落盘
- redis 的持久化方案有 aof 和 rdb，这两种方案在宕机的时候都或多或少的会丢失数据
总结，redis从来没有想过抢 etcd 在服务注册和发现的饭碗，目前的架构来说也抢不动，在缓存方面目前在性能和功能也无出其右； etcd 只关注在服务注册与发现方面，非要当做 k/v 存储来用（丢弃 watch 特性而言）也可以用，性能也不错，但只能说你选错对象了
微服务架构中选择哪种技术，取决于技术决定人的规划理想，非要说 redis 不行当然也是错的，不考虑服务规模和性能需求，用 mongodb 也能搞，mongodb 3.6+版本也有个 oplog watch 的功能
2、redis的使用场景
摘自https://github.com/CyC2018/CS-Notes.git redis一栏
- 计数器：int自增自建
- 缓存：设置内存最大使用量和淘汰策略
- 查找表：DNS记录
- 消息队列：最好还是使用RabbitMQ或者Kafka
- 会话缓存：分布式session
- 分布式锁实现：SETNX或者RedLock
- 其它：set的交集并集操作实现共同好友，排行榜
3、redis的持久化
redis是具有持久化功能的，但是并不完全可靠，两种持久化方法：RDB和AOF
RDB持久化：
将某个时间点的所有数据放到硬盘上，若数据大，时间很长，所以必须关闭该redis服务器，否则部分同步开始后的数据不会备份
AOF持久化：
将写命令添加到 AOF 文件（Append Only File）的末尾。
使用 AOF 持久化需要设置同步选项，从而确保写命令什么时候会同步到磁盘文件上。这是因为对文件进行写入并不会马上将内容同步到磁盘上，而是先存储到缓冲区，然后由操作系统决定什么时候同步到磁盘。有以下同步选项：
选项 同步频率 always 每个写命令都同步 everysec 每秒同步一次 no 让操作系统来决定何时同步 always 选项会严重减低服务器的性能；
everysec 选项比较合适，可以保证系统崩溃时只会丢失一秒左右的数据，并且 Redis 每秒执行一次同步对服务器性能几乎没有任何影响；
no 选项并不能给服务器性能带来多大的提升，而且也会增加系统崩溃时数据丢失的数量。
随着服务器写请求的增多，AOF 文件会越来越大。Redis 提供了一种将 AOF 重写的特性，能够去除 AOF 文件中的冗余写命令。
4、redis的淘汰策略
可以设置内存最大使用量，当内存使用量超出时，会施行数据淘汰策略。
Reids 具体有 6 种淘汰策略：
| 策略 | 描述 |
|---|---|
| volatile-lru | 从已设置过期时间的数据集中挑选最近最少使用的数据淘汰 |
| volatile-ttl | 从已设置过期时间的数据集中挑选将要过期的数据淘汰 |
| volatile-random | 从已设置过期时间的数据集中任意选择数据淘汰 |
| allkeys-lru | 从所有数据集中挑选最近最少使用的数据淘汰 |
| allkeys-random | 从所有数据集中任意选择数据进行淘汰 |
| noeviction | 禁止驱逐数据 |
作为内存数据库，出于对性能和内存消耗的考虑，Redis 的淘汰算法实际实现上并非针对所有 key，而是抽样一小部分并且从中选出被淘汰的 key。
使用 Redis 缓存数据时，为了提高缓存命中率，需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量，然后启用 allkeys-lru 淘汰策略，将最近最少使用的数据淘汰。
Redis 4.0 引入了 volatile-lfu 和 allkeys-lfu 淘汰策略，LFU 策略通过统计访问频率，将访问频率最少的键值对淘汰。
5、ipv4和ipv6
ipv6的好处：
- 一个设备一个公网 IP，不需要穿透，同城毫秒级响应，PT 使用范围 /速度增加
- 可以接入教育网
坏处：
- 一个设备一个公网 IP（喝茶）
- 目前很多网站 ipv6 是单通，而且默认情况下 ipv6 优先级高，所以目前很多情况下启用 ipv6 对网络体验是负优化
- ipv6 路由震荡得厉害，尤其出国，今天美国绕日本，明天日本绕德国，对网络体验还是负优化
6、软链接和硬链接
主要是inode的一些特点和区别，inode会记录除了文件名以外所有的文件信息，包括引用数、权限、组、用户、大小等
1、软链接：ln -s source_file des_file；硬链接：ln source_file des_file
2、两者不管修改什么文件，都是全部修改，但是软/硬链接删除目标文件不影响源文件，删除源文件的话，软的会无效
3、inode中的引用数：硬链接两个文件都会+1，软链接不会；或者说硬链接两个维护一个inode，软链接维护两个inode
4、硬链接不能面向目录
5、硬链接不能分区，软链接可以，使用案例为将日志或者别的大文件软链接到别的硬盘上
7、mysql 为什么不推荐三张表以上的关联？
好处：减少网络io
坏处：
1、不论是几个表，什么 sql，先 show index 看看索引怎么建的，再 explain 分析一波索引命中情况怎样
2、如果条件限制宽泛的话，三张表关联产生的笛卡儿积非常庞大，缓存机制什么的可能扛不住啊，得用 explain 来分析一下了
3、耦合高
4、数据一多，服务器直接GG
