redis

1、redis可扩展性
两种扩展方式：水平扩展、垂直扩展
水平是指增加集群中服务器数量，垂直是指对原有服务器进行扩容，增加硬盘容量
2、redis高可用性
redis集群存在多个主节点，当其中某个主节点宕机，从节点会自动切换到其它主节点下。
3、持久化方式
3.1. 快照方式：（默认持久化方式）
这种方式就是将内存中数据以快照的方式写入到二进制文件中 ，默认的文件名为
dump.rdb。
客户端也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。save 操作是在主线程中保存快照的，由于 redis 是用一个主线程来处理所有客户端的请求，这种方式会阻塞所有客户端请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步增量数据。如果数据量大的话，写操作会比较多，必然会引起大量的磁盘 IO 操作，可能会严重影响性能。
注意：由于快照方式是在一定间隔时间做一次的，所以如果 redis 意外当机的话，就会丢失最后一次快照后的所有数据修改。
3.2. 日志追加方式：
这种方式 redis 会将每一个收到的写命令都通过 write 函数追加到文件中(默认appendonly.aof)。当 redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于操作系统会在内核中缓存 write 做的修改，所以可能不是立即写到磁盘上。这样的持久化还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis 我们想要通过 fsync 函数强制操作系统写入到磁盘的时机。有三种方式如下（默认是：
每秒 fsync 一次）
appendonly yes //启用日志追加持久化方式
#appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
#appendfsync no //完全依赖操作系统，性能最好,持久化没保证
日志追加方式同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用 incr
test 命令 100 次，文件中必须保存全部 100 条命令，其实有 99 条都是多余的。因为要恢复数据库状态其实文件中保存一条 set test 100 就够了。为了压缩这种持久化方式的日志文件。
redis 提供了 bgrewriteaof 命令。收到此命令 redis 将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的持久化日志文件。
4、写数据慢了
原因：为满足高可靠性，开启了aof记录写操作的日志功能，在高并发下写的压力太大。
解决方式：1、增加主节点，分担写的压力
2、redis+ssdb结合来解决写的压力。