Redis高并发

Redis 为单进程单线程模式，采用队列模式将并发访问变为串行访问。

Redis 本身没有锁的概念，Redis 对于多个客户端连接并不存在竞争，但是在业务客户端对 Redis 进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成

以及今天要谈到的Redis并发竞争问题，这里的并发指的是多个redis的client同时set key引起的并发问题。

比如：多客户端同时并发写一个key，一个key的值是1，本来按顺序修改为2,3,4，最后是4，但是由于并发设置的原因，最后顺序变成了4,3,2，最后变成的key值成了2。

采用分布式锁+数据修改的时间戳方案来解决。

①想要向缓存中写入数据时，必须要获得分布式锁，只有获得锁了才可以去进行缓存数据的写入，写入结束释放锁。就可以保证同时只有一个客户端去写缓存。

②可是并不能保证每个客户端获取锁的顺序。但是我们要写入缓存的数据都是从数据库查询出来的，数据库都是有这种数据的创建时间的，所以可以在更新之前，先去对比自己的这条数据的时间和缓存中数据的时间，谁更新，如果自己更新则写入覆盖，否则直接放弃本次操作。

这样就可以保证并发操作时的数据顺序问题。

Redis高性能的原因

一、基于内存实现

Redis 是基于内存的数据库，那不可避免的就要与磁盘数据库做对比。对于磁盘数据库来说，是需要将数据读取到内存里的，这个过程会受到磁盘 I/O 的限制。

而对于内存数据库来说，本身数据就存在于内存里，也就没有了这方面的开销。

二、高效的数据结构 Redis 中有多种数据类型，每种数据类型的底层都由一种或多种数据结构来支持。正是因为有了这些数据结构，Redis 在存储与读取上的速度才不受阻碍。

（1）字符串长度处理用一个 len 字段记录当前字符串的长度。想要获取长度只需要获取 len 字段即可，时间复杂度为 O(1)。

（2）内存重新分配修改字符串的时候会重新分配内存。修改地越频繁，内存分配也就越频繁。而内存分配是会消耗性能的，那么性能下降在所难免。而 Redis 中会涉及到字符串频繁的修改操作，于是 SDS 实现了两种优化策略：

对 SDS 修改及空间扩充时，除了分配所必须的空间外，还会额外分配未使用的空间。

具体分配规则是这样的：SDS 修改后，len 长度小于 1M，那么将会额外分配与 len 相同长度的未使用空间。如果修改后长度大于 1M，那么将分配1M的使用空间。

当然，有空间分配对应的就有空间释放。

SDS 缩短时，并不会回收多余的内存空间，而是使用 free 字段将多出来的空间记录下来。如果后续有变更操作，直接使用 free 中记录的空间，减少了内存的分配。

（3）二进制安全读取字符串遇到 ‘\0’ 会结束，那 ‘\0’ 之后的数据就读取不上了。但在 SDS 中，是根据 len 长度来判断字符串结束的，二进制安全的问题就解决了。

四、合理的数据编码对于每一种数据类型来说，底层的支持可能是多种数据结构，什么时候使用哪种数据结构，这就涉及到了编码转化的问题。

那我们就来看看，不同的数据类型是如何进行编码转化的：

String：存储数字的话，采用int类型的编码，如果是非数字的话，采用 raw 编码；

List：字符串长度及元素个数小于一定范围使用 ziplist 编码，任意条件不满足，则转化为 linkedlist 编码；

Hash：hash 对象保存的键值对内的键和值字符串长度小于一定值及键值对；

Set：保存元素为整数及元素个数小于一定范围使用 intset 编码，任意条件不满足，则使用 hashtable 编码；

Zset：zset 对象中保存的元素个数小于及成员长度小于一定值使用 ziplist 编码，任意条件不满足，则使用 skiplist 编码。

五、合适的线程模型