简介
当业务的数据量和访问量急剧增加的情况下，我们需要对数据进行水平拆分，从而降低单库的压力，并且数据的水平拆分需要对业务透明，屏蔽掉水平拆分的细节。并且，前端业务的高并发会导致后端的数据库连接过多，从而DB的性能低下。
Cobar就是解决这些问题的一款分库分表中间件，Cobar以proxy的形式位于前端应用和后端数据库之间，Cobar对前端暴露的接口是MySQL通信协议，其将前端传输过来的SQL语句按照sharding规则路由到后端的数据库实例上，再合并多个实例返回的结果，从而模拟单库下的数据库行为。
Cobar的使用方法就不多介绍了，本文的主要内容是剖析Cobar的源代码。
Cobar的前端连接模型
结构图如下：
我们先来看CobarServer的代码：
private CobarServer() {
this.config = new CobarConfig();
SystemConfig system = config.getSystem();
MySQLLexer.setCStyleCommentVersion(system.getParserCommentVersion());
this.timer = new Timer(NAME + "Timer", true);
this.initExecutor = ExecutorUtil.create("InitExecutor", system.getInitExecutor());
this.timerExecutor = ExecutorUtil.create("TimerExecutor", system.getTimerExecutor());
this.managerExecutor = ExecutorUtil.create("ManagerExecutor", system.getManagerExecutor());
this.sqlRecorder = new SQLRecorder(system.getSqlRecordCount());
this.isOnline = new AtomicBoolean(true);
this.startupTime = TimeUtil.currentTimeMillis();
}
上面是CobarServer的构造函数，它的限定是private的。
private static final CobarServer INSTANCE = new CobarServer();
public static final CobarServer getInstance() {
return INSTANCE;
}而CobarServer又有一个私有的静态变量INSTANCE，以及获取这个私有静态变量的静态方法，显然，这是一个单例设计模式，使程序运行的时候全局只有一个CobarServer对象。
我们再来看CobarServer的startup()方法，此方法中构造了一个NIOAcceptor（绑定服务器端口，接受客户端的连接），
server = new NIOAcceptor(NAME + "Server", system.getServerPort(), sf);构造了一个接收前端连接的非阻塞Acceptor，让我们在来看NIOAcceptor类的代码。
public final class NIOAcceptor extends Thread {
private static final Logger LOGGER = Logger.getLogger(NIOAcceptor.class);
private static final AcceptIdGenerator ID_GENERATOR = new AcceptIdGenerator();
private final int port;
private final Selector selector;
private final ServerSocketChannel serverChannel;
private final FrontendConnectionFactory factory;
private NIOProcessor[] processors;
private int nextProcessor;
private long acceptCount;
public NIOAcceptor(String name, int port, FrontendConnectionFactory factory) throws IOException {
super.setName(name);
this.port = port;
this.selector = Selector.open(); # 生成选择器
this.serverChannel = ServerSocketChannel.open();
this.serverChannel.socket().bind(new InetSocketAddress(port)); # 绑定服务器端口
this.serverChannel.configureBlocking(false); # 设置非阻塞模式
this.serverChannel.register(selector, SelectionKey.OP_ACCEPT); # 监听ACCEPT事件，
this.factory = factory; # 设置前端连接的工厂
}
}以上的代码都是NIO编程中很常见的操作。下面我们看run()方法，
@Override
public void run() {
final Selector selector = this.selector;
for (;;) {
++acceptCount;
try {
selector.select(1000L); # select操作是阻塞的，若没有监听到相应的事件，则一直阻塞，直到超过1000毫秒，则返回
Set keys = selector.selectedKeys();
try {
for (SelectionKey key : keys) {
if (key.isValid() && key.isAcceptable()) {
accept(); # 接受连接，这个方法很关键
} else {
key.cancel();
}
}
} finally {
keys.clear();
}
} catch (Throwable e) {
LOGGER.warn(getName(), e);
}
}
} 以上的run方法也是常见的NIO中监听事件的套路，其中accept()方法是定义的私有函数，accept方法是为了将channel与selector绑定，代码如下，
private void accept() {
SocketChannel channel = null;
try {
channel = serverChannel.accept(); # 为新的连接分配socket
channel.configureBlocking(false); # 设置为非阻塞模式
# factory将channel进行封装，进行相应的设置，返回一个FrontendConnection，connection本质上就是一个封装好的channel
FrontendConnection c = factory.make(channel);
c.setAccepted(true);
c.setId(ID_GENERATOR.getId()); # 为连接设置ID
NIOProcessor processor = nextProcessor(); # 为连接分配processor，NIOAcceptor中包含了一个NIOProcessor数组，分配的策略即根据下标不断后移，到达数组末尾后又从数组的起始位置开始分配
c.setProcessor(processor);
# 回调NIOProcessor的postRegister方法，而processor的postRegister调用的是NIOReactor类的postRegister方法
processor.postRegister(c);
} catch (Throwable e) {
closeChannel(channel);
LOGGER.warn(getName(), e);
}
}让我来看NIOProcessor的postRegister方法，
public void postRegister(NIOConnection c) {
reactor.postRegister(c);
}NIOProcessor类中定义了一个NIOReactor类的成员变量reactor，而postRegister调用的是NIOReactor的postRegister方法。下面让我们来看NIOReactor的postRegister代码，
final void postRegister(NIOConnection c) {
# 只是先将前端连接插入R线程的阻塞队列中，并没有立刻将channel与selector进行绑定
reactorR.registerQueue.offer(c);
# 唤醒R线程的selector，若之前的select操作没有返回的话则立即返回
reactorR.selector.wakeup();
}既然channel与selector没有立刻进行绑定，那它们是什么时候绑定的呢？我们来看NIOReactor中内部类R的run()方法，
@Override
public void run() {
final Selector selector = this.selector;
for (;;) {
++reactCount;
try {
selector.select(1000L);
# 将connection与selector进行绑定
register(selector);
Set keys = selector.selectedKeys();
try {
for (SelectionKey key : keys) {
Object att = key.attachment();
if (att != null && key.isValid()) {
int readyOps = key.readyOps();
if ((readyOps & SelectionKey.OP_READ) != 0) {
read((NIOConnection) att);
} else if ((readyOps & SelectionKey.OP_WRITE) != 0) {
write((NIOConnection) att);
} else {
key.cancel();
}
} else {
key.cancel();
}
}
} finally {
keys.clear();
}
} catch (Throwable e) {
LOGGER.warn(name, e);
}
}
} 在run方法中，当select方法返回的时候，就会进行channel和selector的绑定，因为当connection插入到阻塞队列中的时候，会对selector进行wakeup()，即select(1000L)方法会立即返回，所以不必担心channel会卡一秒钟才会和selector进行绑定。
我们再来看R线程的register方法，
private void register(Selector selector) {
NIOConnection c = null;
# 将R线程阻塞队列中的所有连接都轮询取出，与selector进行绑定
while ((c = registerQueue.poll()) != null) {
try {
c.register(selector);
} catch (Throwable e) {
c.error(ErrorCode.ERR_REGISTER, e);
}
}
}总结
关于NIOAcceptor为何先将connection放入Reactor的阻塞队列，而不是直接绑定。笔者的观点是，如果由NIOAcceptor负责绑定则会造成锁竞争，selector的register方法会争用锁，会导致NIOAcceptor线程和R、W线程竞争selector的锁，若acceptor中处理绑定connection的逻辑，则NIOAcceptor就不能快速地处理大量的连接，整个系统的吞吐就会降低。所以Cobar中的设计是将connection的绑定放到R线程的阻塞队列中去，让R线程来完成connection的绑定工作。
图就随意看看吧-.-，有点丑。
以上。
原文链接
https://segmentfault.com/a/11...