福建建设厅安全员报名网站,有了自己的网站怎么赚钱,重庆便宜做网站的,世界杯排名如果我有一个32核心的服务器#xff0c;我就可以实现1个亿的数据分片#xff0c;我有32核心的服务器么#xff1f;没有#xff0c;所以我至今无法实现1个亿的数据分片。——MyCAT ‘s Plan
话说“每一个成功的男人背后都有一个女人”#xff0c;自然MyCAT也逃脱不了这个诅…如果我有一个32核心的服务器我就可以实现1个亿的数据分片我有32核心的服务器么没有所以我至今无法实现1个亿的数据分片。——MyCAT ‘s Plan
话说“每一个成功的男人背后都有一个女人”自然MyCAT也逃脱不了这个诅咒MyCAT背后是阿里曾经开源的知名产品——Cobar核心功能和优势是MySQL数据库分片此产品曾经广为流传据说最早的发起者对Mysql很精通后来从阿里跳槽了阿里随后开源的Cobra并维持到2013年年初然后就没有然后了。
Cobra的确做的很不错基于Java实现了MySQL二进制协议因此可以将自己伪装成一个MySQL Server并且很多MySQL客户端都能访问这个做法很好比自己实现一个新的数据库协议要明智的多因为生态环境在哪里摆着。
由于是Java开发的下载下来解压只要配置几个不是很复杂的配置文件猛击鼠标就能启动Cobra因此这个开源产品赢得了很多Java粉丝的追捧当然笨人也跟着进入并且在某个大型云项目中——“苦海无边”的煎熬过。
爱情就像是见鬼你根本不知道鬼是怎样的只有撞见鬼以后你才真正明白什么是爱情。爱情也会很快褪色你不会告诉TA你不好的地方你会拼命将你的优点无限放大就差把自己当成世界上第二伟大的人了。相信每个用过Cobra的人都经历了这样的过程围城里的人已经出不来了但还有更多的人拼命想挤进来。
仅以此文献给哪些努力在IT界寻求未来的精英们以及小白们还有更多被无视的就差要打算转行的同仁人同在江湖混不容易啊面试时候就装装糊涂放人家一马说不定以后又是一个Made in China的乔布斯啊。 关于Cobra的十个秘密 第一个秘密纳尼Cobra会假死
Cobra的确会假死很多人遇到这个问题如何简单的来验证这点呢我们来做个小实验假如你的分片表中配置有表company,则打开mysql终端执行下面的SQL
select sleep(500) from company;
此SQL会执行等待500秒你再努力以最快的速度打开N个mysql终端都执行相同的SQL确保N当前Cobra的执行线程数show threadpool的所有Processor1-E的线程池的线程数量总和然后你再执行任何简单的SQL或者试图新建立连接都会无法响应此时show threadpool里面看到TASK_QUEUE_SIZE已经在积压中。
不可能吧据说Cobra是NIO的非阻塞的怎么可能阻塞别激动去看看代码Cobra前端是NIO的而后端跟Mysql的交互是阻塞模式其NIO代码只给出了框架还未来得及实现。真相永远在代码里所以为了发现真相还是转行去做码农吧貌似码农也像之前的技术工人越来越稀罕了。
第二个秘密高可用的陷阱
每一个秘密的背后总是隐藏着更大的秘密。Cobra假死的的秘密背后还隐藏着一个更为“强大”的秘密那就是假死以后Cobra的频繁主从切换问题。我们看看Cobra的一个很好的优点——“高可用性”的实现机制下图解释了Cobra如何实现高可用性 分片节点dn2_M1配置了两个dataSource并且配置了心跳检测(heartbeat)语句在这种配置下每个dataNode会定期对当前正在使用的dataSource执行心跳检测默认是第一个频率是10秒钟一次当心跳检测失败以后会自动切换到第二个dataSource上进行读写假如Cobra发生了假死则在假死的1分钟内Cobra会自动切换到第二个节点上因为假死的缘故第二个节点的心跳检测也超时。于是1分钟内Cobra频繁来回切换懂得MySQL主从复制机制的人都知道在两个节点上都执行写操作意味着什么——可能数据一致性被破坏谁也不知道那个机器上的数据是最新的。
还有什么情况下会导致心跳检测失败呢这是一个不得不说的秘密当后端数据库达到最大连接后会对新建连接全部拒绝此时Cobar的心跳检测所建立的新连接也会被拒绝于是心跳检测失败于是一切都悄悄的发生了。
幸好大多数同学都没有配置高可用性或者还不了解此特性因此这个秘密一直在安全的沉睡。
第三个秘密看上去很美的自动切换
Cobar很诱人的一个特性是高可用性高可用性的原理是数据节点DataNode配置引用两个DataSource并做心跳检测当第一个DataSource心跳检测失败后Cobar自动切换到第二个节点当第二个节点失败以后又自动切换回第一个节点一切看起来很美无人值守几乎没有宕机时间。
在真实的生产环境中我们通常会用至少两个Cobar实例组成负载均衡前端用硬件或者HAProxy这样的负载均衡组件防止单点故障这样一来即使某个Cobar实例死了还有另外一台接手某个Mysql节点死了切换到备节点继续至此一切看起来依然很美喝着咖啡听着音乐领导视察你微笑着点头——No problemEverything is OK!直到有一天某个Cobar实例果然如你所愿的死了不管是假死还是真死你按照早已做好的应急方案优雅的做了一个不是很艰难的决定——重启那个故障节点然后继续喝着咖啡听着音乐轻松写好故障处理报告发给领导然后又度过了美好的一天。 你忽然被深夜一个电话给惊醒你来不及发火因为你的直觉告诉你这个问题很严重大量的订单数据发生错误很可能是昨天重启cobar导致的数据库发生奇怪的问题。你努力排查了几个小时终于发现主备两个库都在同时写数据主备同步失败你根本不知道那个库是最新数据紧急情况下你做了一个很英明的决定停止昨天故障的那个cobar实例然后你花了3个通宵解决了数据问题。 这个陷阱的代价太高不知道有多少同学中枪过反正我也是躺着中枪过了。若你还不清楚为何会产生这个陷阱现在我来告诉你
Cobar启动的时候会用默认第一个Datasource进行数据读写操作当第一个Datasource心跳检测失败会切换到第二个Datasource若有两个以上的Cobar实例做集群当发生节点切换以后你若重启其中任何一台Cobar就完美调入陷阱
那么怎么避免这个陷阱目前只有一个办法节点切换以后尽快找个合适的时间全部集群都同时重启避免隐患。为何是重启而不是用节点切换的命令去切换想象一下32个分片的数据库要多少次切换
MyCAT怎么解决这个问题的很简单节点切换以后记录一个properties文件 conf目录下重启的时候读取里面的节点index真正实现了无故障无隐患的高可用性。
第四个秘密只实现了一半的NIO NIO技术用作JAVA服务器编程的技术标准已经是不容置疑的业界常规做法若一个Java程序员没听说过NIO都不好意思说自己是Java人。所以Cobar采用NIO技术并不意外但意外的是只用了一半。 Cobar本质上是一个“数据库路由器”客户端连接到Cobar发生SQL语句Cobar再将SQL语句通过后端与MySQL的通讯接口Socket发出去然后将结果返回给客户端的Socket中。下面给出了SQL执行过程简要逻辑
SQL-FrontConnection-Cobar-MySQLChanel-MySQL FrontConnection 实现了NIO通讯但MySQLChanel则是同步的IO通讯原因很简单指令比较复杂NIO实现有难度容易有BUG。后来最新版本Cobar尝试了将后端也NIO化大概实现了80%的样子但没有完成也存在缺陷。 由于前端NIO后端BIO于是另一个有趣的设计产生了——两个线程池前端NIO部分一个线程池后端BIO部分一个线程池。各自相互不干扰但这个设计的结果导致了线程的浪费也对性能调优带来很大的困难。 由于后端是BIO所以也是Cobar吞吐量无法太高、另外也是其假死的根源。 MyCAT在Cobar的基础上完成了彻底的NIO通讯并且合并了两个线程池这是很大一个提升。从1.1版本开始MyCAT则彻底用了JDK7的AIO有一个重要提升。
第五个秘密阻塞、又见阻塞 Cobar本质上类似一个交换机将后端Mysql 的返回结果数据经过加工后再写入前端连接并返回于是前后端连接都存在一个“写队列”用作缓冲后端返回的数据发到前端连接FrontConnection的写队列中排队等待被发送而通常情况下后端写入的的速度要大于前端消费的速度在跨分片查询的情况下这个现象更为明显于是写线程就在这里又一次被阻塞。 解决办法有两个增大每个前端连接的“写队列”长度减少阻塞出现的情况但此办法只是将问题抛给了使用者要是使用者能够知道这个写队列的默认值小了然后根据情况进行手动尝试调整也行但Cobar的代码中并没有把这个问题暴露出来比如写一个告警日志队列满了建议增大队列数。于是绝大多数情况下大家就默默的排队阻塞无人知晓。 MyCAT解决此问题的方式则更加人性化首先将原先数组模式的固定长度的队列改为链表模式无限制并且并发性更好此外为了让用户知道是否队列过长了一般是因为SQL结果集返回太多比如1万条记录当超过指定阀值可配后会产生一个告警日志。
systemproperty namefrontWriteQueueSize1024/property/system
第六个秘密又爱又恨的SQL 批处理模式 正如一枚硬币的正反面无法分离一块磁石怎样切割都有南北极爱情中也一样爱与恨总是纠缠着无法理顺而Cobar的 SQL 批处理模式也恰好是这样一个令人又爱又恨的个性。 通常的SQL 批处理是将一批SQL作为一个处理单元一次性提交给数据库数据库顺序处理完以后再返回处理结果这个特性对于数据批量插入来说性能提升很大因此也被普遍应用。JDBC的代码通常如下
String sql insert into travelrecord (id,user_id,traveldate,fee,days) values(?,?,?,?,?);
ps con.prepareStatement(sql);
for (MapString, String map : list) {ps.setLong(1, Long.parseLong(map.get(id)));ps.setString(2, (String) map.get(user_id));ps.setString(3, (String) map.get(traveldate));ps.setString(4, (String) map.get(fee));ps.setString(5, (String) map.get(days));ps.addBatch();
}
ps.executeBatch();
con.commit();
ps.clearBatch(); 但Cobar的批处理模式的实现则有几个地方是与传统不同的
提交到cobar的批处理中的每一条SQL都是单独的数据库连接来执行的批处理中的SQL并发执行
并发多连接同时执行则意味着Batch执行速度的提升这是让人惊喜的一个特性但单独的数据库连接并发执行则又带来一个意外的副作用即事务跨连接了若一部分事务提交成功而另一部分失败则导致脏数据问题。看到这里你是该“爱”呢还是该“恨”
先不用急着下结论我们继续看看Cobar的逻辑SQL并发执行其实也是依次获取独立连接并执行因此还是有稍微的时间差若某一条失败了则cobar会在会话中标记”事务失败需要回滚“下一个没执行的SQL就抛出异常并跳过执行客户端就捕获到异常并执行rollback回滚事务。绝大多数情况下数据库正常运行此刻没有宕机因此事务还是完整保证了但万一恰好在某个SQL commit指令的时候宕机于是杯具了部分事务没有完成数据没写入。但这个概率有多大呢一条insert insert 语句执行commit指令的时间假如是50毫秒100条同时提交最长跨越时间是5000毫秒即5秒中而这个C指令的时间占据程序整个插入逻辑的时间的最多20%假如程序批量插入的执行时间占整个时间的20%已经很大比例了那就是20%×20%4%的概率假如机器的可靠性是99.9%则遇到失败的概率是0.1%×4%十万分之四。十万分之四意味着99.996%的可靠性亲可以放心了么
另外一个问题即批量执行的SQL通常都是insert的插入成功就OK失败的怎么办通常会记录日志重新找机会再插入因此建议主键是能日志记录的用于判断数据是否已经插入。
最后假如真要多个SQL使用同一个后端MYSQL连接并保持事务怎么办就采用通常的事务模式单条执行SQL这个过程中Cobar会采用Session中上次用过的物理连接执行下一个SQL语句因此整个过程是与通常的事务模式完全一致。
线程池一个连接要在可用之前做如下同步指令
12:34:37.044 DEBUG [Processor1-E3] (MySQLConnection.java:325) -org.opencloudb.mysql.nio.MySQLConnection$StatusSync15aaf0b3need syn schemaCmd MySQL Command Packet{length0,id0}need syn charCmd MySQL Command Packet{length0,id0}need syn txIsolationCmd MySQL Command Packet{length0,id0}need syn autcommitCmd MySQL Command Packet{length0,id0}
后端物理连接是有限的只能一个线程使用因此最佳的连接池是 基于DB Server的而不是基于DB Server的的某一个database上另外为了最有效的获取一个“合适的连接”需要判断某个空闲连接的上述4个指令是否与想要得到的连接的请求参数“最大匹配”目前没有研究过开源的其他Java连接池是否有此功效Mycat中目前已经按照此策略进行了最大可能的优化
