TechNomads

利用redis来实现分布式锁。一般就用setnx和getset两个命令。 NX是Not eXists的缩写，如SETNX命令就应该理解为：SET if Not eXists. getset是同步的 java之jedis实现 expireMsecs 锁持有超时，防止线程在入锁以后，无限的执行下去，让锁无法释放 timeoutMsecs 锁等待超时，防止线程饥饿，永远没有入锁执行代码的机会 代码如下： private int timeoutMsecs private String lockKey private static long expireMsecs = 1000 * 60 * 5 // min 锁持有超时 // timeoutMsecs 表示锁等待超时 public JedisLock(Integer timeoutMsecs, String lockKey) { this.timeoutMsecs = timeoutMsecs this.lockKey = lockKey } public synchronized boolean acquire(Jedis jedis) th....

我觉得最重要的一点是，redis作为一个内存数据库，内存操作是很快的。网络io是瓶颈，如果用多线程，还要引起线程切换，线程切换的开销是很大的，切换线程之后要保留现场，要做很多预处理。所以用单线程反而能起到更好的作用。 线程切换为什么开销大呢？举个简单的例子，我在看一篇文章，有个单词不认识，那我要去查词典。在查词典之前，我得要先记录我阅读到了那一页的哪一行，方便下次来继续读。那这样肯定是要影响我读书效率的。 我总结几点redis为什么要设计成单线程的原因 都是通过网络来调用redis的，如果是内网调用情况稍微比外网调用好点。但是这些和内存操作的时间不是一个量级的。用单线程处理完全能应付。 redis是采用单线程-多路复用IO模型来实现高性能内存数据服务的。这样就避免了适用锁。网络层利用IO多路复用，这使用了内核级别的线程池，就是说还是存在并发的，只是在网络层的并发。但是网络Io本身是很慢的。是瓶颈。那么你在业务处理阶段设计再多的线程，使用再多的cpu内核，也没法逾越网络Io的瓶颈。 redis和传统的多线程服务器不同。比如tomcat这些，后端往往存在很重的IO操作，会产生长时间的等待....