简介
当业务的数据量和访问量急剧增加的情况下,我们需要对数据进行水平拆分,从而降低单库的压力,并且数据的水平拆分需要对业务透明,屏蔽掉水平拆分的细节。并且,前端业务的高并发会导致后端的数据库连接过多,从而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<SelectionKey> 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<SelectionKey> 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的绑定工作。
图就随意看看吧-.-,有点丑。
以上。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。