今天的文章主要讲为什么要去用redis,以及怎么去解决redis的并发竞争key问题。内容如下：

为什么要用redis

为什么要用redis呢，下面通过性能和并发两个维度简单解释下：

1、性能

如下图所示，我们在碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存。这样，后面的请求就去缓存中读取，使得请求能够迅速响应。

2、并发

如下图所示，在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问数据库。

既然要用redis，那我们又怎么去解决redis的并发竞争key问题呢？

如何解决redis的并发竞争key问题

问题来源：同时有多个子系统去set一个key。这个时候要注意什么呢？大家思考过么。

需要说明一下，小编提前百度了一下，发现答案基本都是推荐用redis事务机制。小编是不太推荐使用redis的事务机制。因为我们的生产环境，基本都是redis集群环境，做了数据分片操作。你一个事务中有涉及到多个key操作的时候，这多个key不一定都存储在同一个redis-server上。因此，redis的事务机制，十分鸡肋。

解决办法：

(1)如果对这个key操作，不要求顺序

这种情况下，准备一个分布式锁，大家去抢锁，抢到锁就做set操作即可，比较简单。

(2)如果对这个key操作，要求顺序

假设有一个key1,系统A需要将key1设置为valueA,系统B需要将key1设置为valueB,系统C需要将key1设置为valueC.

期望按照key1的value值按照 valueA–>valueB–>valueC的顺序变化。这种时候我们在数据写入数据库的时候，需要保存一个时间戳。假设时间戳如下

系统A key 1 {valueA 3:00}

系统B key 1 {valueB 3:05}

系统C key 1 {valueC 3:10}

那么，假设这会系统B先抢到锁，将key1设置为{valueB 3:05}。接下来系统A抢到锁，发现自己的valueA的时间戳早于缓存中的时间戳，那就不做set操作了。以此类推。

其他方法，比如利用队列，将set方法变成串行访问也可以。

上面是小编比较推荐的方法解决redis的并发竞争key问题，大家有空也可以尝试下。

PS：后期会主要分享一些底层的内容，大家有兴趣的话可以关注下哦~