问题的提出
我们知道，在单机的“线程模型“中，2个线程并发修改一个变量，是需要加锁的。这个在Java并发编程–序列1已经讲过，要么是悲观锁，要么是乐观锁。
如果把单机的线程模型，改成有客户端/服务器的进程模型。服务器可以是Mysql/Redis/Memcached任何一种，那该问题又如何解决呢？
方案1 – 单条命令的原子性
Mysql: 用类似update table set x = x + 1 where … 这样的单条语句就可解决上述问题，因为服务器内部会处理加锁的问题，不用客户端解决。
Memcached: incr/decr命令
Redis: incr/decr命令
一句话：对于这种简单的整数加减的原子操作，只要是1条命令可以搞定，就不需要客户端解决互斥问题。
方案2 – Memcached/Redis的乐观锁
上面的方案1，必须是单条命令，但该方法有很大局限性。很多时候，如果我们需要执行复杂的计算逻辑，要先把数据get出来，执行复杂逻辑，再set回去。类似下面这种：
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
此时有2条指令，没有办法保证2条语句的原子性，这个时候如何解决呢？
Mysql的乐观锁
关于Mysql解决上述问题的乐观锁方案，此处不再详述，参见Java并发编程-序列1
Memcached乐观锁
Memcached提供了2个命令 gets + cas。gets取出数据的时候，同时返回版本号；修改之后, cas回去的时候，会比较该版本号和服务器上最新的版本号。如果不等，则cas失败。
Redis乐观锁
Redis提供了watch命令，如下所示：
- 1
- 2
- 3
- 4
- 5
- 6
方案3 – Redis事务
Redis也提供了事务的概念，但它不能回滚。如果1条命令执行错误，会继续执行下面的。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
此处的multi/extc，类似Mysql中的beganTransaction/endTransaction。
另外，由于redis是单线程的，因此事务里面的多条语句执行时，不会被打断。
Memcached的多线程 vs. Redis单线程
我们都知道, Memcached内部是多线程的，而Redis是单线程的。多线程好理解，但Redis为什么要搞成单线程呢？
个人认为，有以下几个原因：
（1）redis有各种复杂的数据结构list, has, set。也就是说，对于一个(key, value)，value的类型可以是list, hash, set。在实际应用场景中，很容易出现多个客户端对同一个key的这个复杂的value数据结构进行并发操作，如果是多线程，势必要引入锁，而锁却是性能杀手。
相比较而言，memcached只有简单的get/set/add操作，没有复杂数据结构，在互斥这个问题上，没有redis那么严重。
（2）对于纯内存操作来说，cpu并不是瓶颈，瓶颈在网络IO上。所以即使单线程，也很快。另外，如果要利用多核的优势，可以在一个机器上开多个redis实例。
