数据库SQL查询的数次轮回

只要没有客户端连接上服务器，accept方法就一直不能返回，这就是阻塞;对应的读写操作道理也一样，想要读取数据，必须等到有数据到达才能返回，这就是阻塞。

我们还可以站在阻塞的基础上思考一下，为什么服务器的模型要设计成来一个客户端就新建一个线程?

其实答案很简单，当来了一个客户端创建连接后，如果不给客户端新分配一个线程执行服务器逻辑，那么服务端将很难再和第二个客户端建立连接。

就算你把客户端连接用集合保存起来，通过单线程遍历集合的方式去执行服务器端逻辑也是不行的。因为如果某个客户端连接因为读写操作阻塞了，那么其他客户端将得不到执行。

NIO

如果说服务器只有很少的人用，那么上面那段bio的代码其实挺好的，但问题在于互联网蓬勃发展，随着服务器访问人数的增加，这样的服务器模型将会成为瓶颈。

我们以一种C10K的思想去看待上面这段服务器代码。如果我们客户端的连接数增加了10K倍，那么就意味着要创建10k个线程，单单创建线程就是一项不小的开销了，再加上线程之间要来回切换，单机服务器根本就扛不住这么大的连接数。

那既然瓶颈是出在线程上，我们就考虑能不能把服务器的模型变为单线程模型，思路其实和之前说的差不多，用集合保存每个连接的客户端，通过while循环来对每个连接进行操作。

之前我们说了这样的操作瓶颈在于accept客户端的时候会阻塞，以及进行读写操作的时候会阻塞，导致单线程执行效率低。为了突破这个瓶颈，操作系统发展出了nio，这里的nio指的是非阻塞io。

也就是说在accept客户端连接的时候，不需要阻塞，如果没有客户端连接就返回-1(java-NULL)，在读写操作的时候，也不阻塞，有数据就读，没数据就直接返回，这样就解决了单线程服务器的瓶颈问题。示例代码如下：

 

阿粉第一次了解到io相关知识是在网上看面经的时候，平时只会写业务代码，面对bio，nio，多路复用器这些概念简直是一头雾水。

当阿粉尝试单独去学习这些名词，发现很难学懂，如果能有一篇文章串起来讲讲他们的关系，可能对初学者来说有一定的帮助，所以便有了下面这篇文章。

BIO

BIO即为阻塞IO的意思，通常我们讲BIO的时候都会和服务器模型配合着讲，在实际应用中讲会更好理解。大家看下面的代码，估计在大家初学java网络编程的时候用的都是这个模型：

 

它对节点的要求也是比较多的，一般是采用6个节点，三主三从。当节点超过10个，它的协调性就不那么灵活了，所以单集群的存储和性能上限也很快能到达。

集群模式的一些缺点很隐蔽。它的服务端节点倒是非常稳定了，但有些命令会严重影响性能。比如mget,pipeline等。它们需要把请求分散到多个节点执行、再聚合。节点越多，性能越低。

在下面这篇文章中，我们详细的描述了一些比较通用的redis使用规范，有些就是为了规避cluster模式引起的一些问题。

其他方案

可以看到redis的这些集群模式，都不是完美的。应对小型的服务可能没有问题，如果是大型的集群和服务，这些部署方式对运维上，使用上来说，都有非常大的挑战。

使用客户端hash的方法，是大型互联网中常用的方式。参考下面的文章，现实中的路由规则，可能会相当复杂，但请求总能够精确的落在某个小的群组上面。

对于管理大型集群来说，我倒是倾向于主从模式，然后使用Java或者其他语言开发一个可以集中管控的哨兵系统，对上千个集群进行管理。

由于Redis是文本协议，协议非常简单，Netty甚至直接内置了它的解析器，所以开发这么一个哨兵系统是非常简单的。

一些中间层代理软件，也能分担一些路由工作，但由于是中间层，涉及到一层网络转发，对Redis这种以速度取胜的服务来说，就不是很实用。

变种有更多，比如下面这篇文章，使用的是Redis协议，但后端存储却是MySQL，所以你的命令会是被阉割的。

从上面的描述中我们就可以看出，Redis能用是一回事，用好是另一回事。

你可能花了一天时间搭建了一个单节点的Redis；我可能花了一周时间写了个Java版的哨兵，还有很多BUG。这两者在不懂技术的领导眼里，是没有区别的--它们都满足了业务的需求。但也不必过分计较，现实一般都比较残酷，计算机系统也没有想象中的那么稳定，墨菲定律总有一个时间会教会他们做人。

当然，领导每天都在教我做人。

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!