《二零一六中国系统架构师大会_去IOE关键技术分析_吕海波(新)》.pdf

去IOE关键技术分析 演讲人：吕海波（VAGE ） 内容介绍 •  互联网企业去O关键技术分析： Sharding •  去，还是不去 ！ •  O的替补 互联网企业去O关键技术分析：Shanding Sharding，是Sharde-nothing 的缩写，有些地方也就horizontal paroning/horizontal split，也就是数据库切片。简单点说，就是将一张大 表，拆分到N个数据库中。咱们后面，用一个更形象的词称它：拆表。 对并发比较高的数据库进行去O时，一定要考虑拆表。哪么，问题来了： 为什么要拆表 非O数据库目前的并发机制，不如Oracle 更加强大。这个短板，通过拆表来弥补最 为方便。 （注：本文中非O数据库主要以MySQL为例，不代表所有非O数 据库） 决定并发的因素：锁。锁粒度的大小等锁 机制决定了并发程度。 去O关键技术 -- 拆表 ：架构师读书问题 （有一个著名的讨论线程同步的问题，叫哲学家就餐问题，我也东施效颦，来个架构师 读书问题）： 假设5个架构师要读同一本纸制书： 书只有一本，人有5名，为了避免打架，方法就是将书装进一个盒子中锁上，有一把钥 匙可以打开这个盒子得到书，这把钥匙我们称为Book Key （简称BK）。 5名架构师谁先得到BK，就能打开盒子，得到书，然后开始读书。而其他人就只能等着。 这种方式资源使用率有限，并发不高。 去O关键技术 -- 拆表 ：架构师读书问题 如何提高并发呢， “细化锁的粒度”。 比如5名架构师分别是A 、B、C、D和E。这本 《Oracle 内核技术揭密》共有7章，假设5名 架构师分别想看不同的章，A想看第4章，共享池原理。B想看第3章，Buffer Cache原理， C想看第6章，Redo原理，等等。 那么问题就很简单了，将书拆开，按章节拆成多本。一共7章，就拆成7本，分别装在7 个盒子中，每个盒子都有一把钥匙，可以打开盒子，得到书的某一章。这样就有了7个 盒子、7把钥匙。这7个钥匙分别编号为BK1，2，3……7 。 A想看第4章，他只需要得到BK4，打开锁得到盒子中的第4章，就可以了。A可以拿着第4 章自己看个够，不影响B同一时间看第3章，C在同一时间看第5章等等。这样，A 、B、C、 D和E 5名架构师可以同时读书了。并发得到提高，系统资源利用的更加充分。 去O关键技术 -- 拆表 ：架构师读书问题 细化锁的粒度可以有效的提高并发，但这并不是一件容易的工作。 比如，下面这个问题，如果有多名架构师要读同一章怎么办？如何进一步提升“架构师 读书问题”的并发？ 这个问题很简单，将每一章再拆成页，A看第1页，B看第5页，等等。 去O关键技术 -- 拆表 ：架构师读书问题 但这个问题只是看似简单。 《Oracle 内核技术揭密》共有400页，将书拆成页后，每一页 都要有一个锁保护，锁的数量就是400 。 看到没，锁从1个，拆成章后变成6个，拆成页后变成400个，越来越多。锁并不是凭空 而来的东西，它要占内存，处理它要耗CPU资源。 将书拆成页后，现在你看书的步骤是这样的： 查找第一页的锁 判断是否可以得到它 如果可以得到，持有它 开始阅读第一页 释放第一页的锁，查看有无其他人在等待，有的话通知他可以持有了 查找第二页的锁 判断是否可以得到它 如果可以得到，持有它 开始阅读第二页 释放第二页的锁，查看有无其他人在等待，有的话通知他可以持有了 ……………… 去O关键技术 -- 拆表 ：架构师读书问题 这就是锁太细、太多的问题。我们今天不讨论锁的设计，只是说明一个问题，并发的提 高 ，不是想提你就提。 回过头说拆表的问题。 Oracle在各种锁机制（或者说并发机制）上，还是下足了工夫的，比很多其他数据库要 好。比如说，MySQL。 MySQL在将重做日志数据写到Redo lo