哈哈哈哈

MOM的好处是什么？
想象一个没有快递公司的世界吧。发件人要放下手头的工作，千里迢迢地把货物送给收件人。如果收件人不在家，要么带着货物回家，要么继续等待。这个过程不合理的原因在于，货物的发送是一个同步过程。发件人在货物运送的过程中，完全不能处理其他事情。假设路途遥远，或者收件人经常不在家，发件人的时间会白白浪费。
快递公司存在的意义在于解放了发件人的生产力。MOM也是如此。

整体架构图如下：

上面是对MOM的一个简单介绍。下面开始讨论本文的重点——如何持久化MOM的数据。

一、本地持久化
作为分布式服务，MOM本身就运行在多个app服务器上。最为简陋的一种实现方式是，不对消息进行任何持久化。MOM把接收到消息存放到内存队列里面。如果消息堆积（接收）的速度大于消息消耗（发送），可以按照优先级抛弃相对不太重要的消息，以保证内存不会溢出。然而这样做的弊端也很明显。假如app服务器意外重启，所有消息不论重要性如何都会丢失。
简单的改进方法是把接收到消息以日志的形式，顺序写入到本地磁盘。同时持久化一个checkpoint来保证日志的可重复利用率，以免磁盘被已发送的消息撑满。如果数据比较重要，最好在app服务器上做RAID，以避免磁盘损坏丢失信息。
结构图如下所示：

二、数据库持久化
简单的MOM设计，只能支持最原始的消息接收和转发，无法支持多维度的查询和复杂业务逻辑的处理。
举例来说，按消息类型、重发次数来决定应该优先发送哪些消息这个功能，就需要MOM较大的改动。为了使MOM同时满足代码简洁和支持复杂业务的要求，在持久层引入数据库看似是理所当然的选择。

在MOM中引入数据库，还有一个好处是减少app服务器的硬件成本。app服务器上不存任何持久化数据，那么也就不需要为app服务器配备RAID卡和冗余磁盘，内存和cpu的投入也可以相应减少。当然，这些成本要投入到MySQL上。总体成本并不一定会降低。

三、分布式持久化
无论是持久化到app的本地磁盘，还是持久化到MySQL，都不能避免数据单点。简单说，就是数据没有备份。
在比较严格的应用场景下，消息中间件需要提供99.99%的数据安全性，甚至要经受得住机房地震之类的自然灾害。在不改动MOM代码的情况下，有三种方式可以实现数据安全性：
第一种是MySQL自带的Replication方案，通过主备库实时同步，能够保证堆积消息的数据安全。但是因为Binlog的异步复制策略，MOM接收的最新消息可能会丢失；
第二种方式是Google的Semi-replication，在这个补丁的帮助下MySQL能够实现Binlog同步复制，保证MOM接收到的所有消息都不会丢失；

第三种方式是DRBD，通过模拟存储级别的数据同步机制，DRBD很好地保证了数据安全性，对整个MOM系统的部署方案改动也非常小。

除此之外，我要向大家推荐一下XA（分布式事务）方案。假设有两台MySQL服务器，MOM可以起一个分布式事务，分别向两者写入一条数据，删除数据时亦然。不过考虑到XA的性能问题，需要在设计上做一些折中。

根据CAP原理，一致性、高可用性和数据分布特性会玩跷跷板。同时追求CAP的三个因子，无法避免地会降低系统的性能（响应时间、吞吐量等）。如果我们的设计能够做到数据只多不少，那么也在一定程度上保证了数据安全性，同时也可以做到高性能，是一个很好的解决方案。具体怎么做，就仁者见仁了。

她6岁的时候，预见了36岁、光着身子穿梭而来的他；
她20岁的时候，28岁的他以为是初次见面；
她23岁的时候，31岁的新郎在婚礼上再次穿越，头发已经灰白的他赶场解围；

他和她生了一个漂亮聪明的小女孩，能够自由控制穿梭；
来自未来的女儿告诉他，自己五岁的时候他会死去。他抱住了小女孩，不知所措。
日子在穿梭中流逝，他在不同的时空中不断补全自己因为穿梭而失去的那些，关于相识和相爱的经历……

43岁，他办了个聚会，和妻子、好友一一道别，穿梭到另外一个时空被岳父误伤而死。

————————————————————–
“如果死亡是注定的结果，那就让我们享受生命里那些并不确定的过程”

一、望远镜不是好抢的！
由于技术上的失误，我们三个人上鼓浪屿的时候，坐了15块钱/人的游览船。船开了一会会，某处的喇叭就开始喊“船上有望远镜，大家可以到前面来拿，看看海峡对面的风景”。我和光哥正四处张望哪里有望远镜时，均量已经得意地拿着望远镜出现在我们面前。三个人很二地蹲在船头看着n远的台湾，废了半天劲什么都没看见。过了会，船上的水手过来收取每个望远镜十块的使用费。当时我们的冲动是趁他不注意把望远镜扔进海里，来个死无对证。幸好我们是社会主义好青年，所以乖乖付了十块钱。

二、便利贴是用来说倾诉的～
不管是龙头大排档，还是张三疯欧式奶茶店，墙上都贴满了客人们亲手写的便利贴。
有独自旅行者对未来自己的寄托，有小两口浓情蜜意的见证，偶尔也有饥渴者留下的电话号码和好事者的备注。

三、每家都有小别墅
鼓浪屿上别墅到处都是，几乎家家户户都住的是别墅，只是装修有差异罢了。
家庭旅馆的兴起，使得鼓浪屿上的别墅着实火了一把。又能自己住又能赚钱，何乐不为呢？

四、酒吧很多很生猛
世界杯决赛那天，我们半夜跑去酒吧看比赛。赛前老板决定放点电影，光哥要求来点刺激的。
老板突然眼神一变，很正气凛然地说：“K粉要不要？一万一条！要不要？”
于是我们几个很安静地闭嘴了……

五、海景很脏很丑陋
虽然说鼓浪屿是个著名的旅游景点，但是海水真的很脏。
跳进充满垃圾和泥沙的海水中，需要不亚于直面房价的勇气。
奇怪的是，这样的海水，居然还能撑起好几个海水浴场。相当崩溃……

六，没吃沙茶面，好遗憾……
这次实在是没空吃沙茶面了。幸好八月中旬技术保障部组织了一次厦门outting。
嘿嘿，正好把沙茶面补上~

第二天早上，我们绕到海滨浴场去吃海鲜。据说码头那边很贵，我们没问过价钱。海鲜都装在大脸盆里面，有虾有蟹有鱼。还有些莫名其妙的东西，比如说禁售的海怪，长得跟蛇很像的海鳗等等。

我们点了几样常见的海鲜，还有炒粉干，很快就上菜了。



前面两样是虾和海瓜子，最后一样是蝤蛑（海螃蟹）。因为没什么经验，挑的那两只蝤蛑不是很肥。
不过总体来说，味道非常不错，价钱也很合理。特别是坐在海边，在太阳伞下吹着海风，吃着海鲜，那种感觉真的很惬意！

在海边走着，会时不时看见烧烤摊。我怂恿均量和成光买了烤秋刀鱼。三下两除二就吃成了骨架，汗……

接着介绍下饮品。七月份去鼓浪屿是很热的，不光是气氛很热闹，温度也很高。如果不及时补充水分，肯定会脱水。
幸好鼓浪屿上有各种各样的饮品，保证走到哪里喝到哪里，而且公共厕所挺多，不用担心找不到地方方便。
最给力的公路饮品，冰镇椰子。肾功能是否强大，就看你一路能喝几个椰子！

大名鼎鼎的张三疯。最好喝的肯定是招牌奶茶，据说原料很简单，雀巢奶粉＋斯里兰卡进口红茶＋绝密果仁葡萄干。


鼓浪屿加强版龟苓膏，烧仙草！下面的烧仙草是在“赵小姐的店”里面吃的。说实话，我很不喜欢吃龟苓膏，但是这次觉得很好吃！
烧仙草的最大功效就是降火，夏天在空调包厢里吃一份凉凉的烧仙草，顿时感觉温度下来了。

鼓浪屿上还有各种鲜榨果汁。各种水果在眼前榨成浓缩果汁，缓缓流出，价钱也很便宜。下面的照片是一个很凶残的榨汁机，橙子一个一个进去，榨成了一小杯一小杯的橙子汁……

再介绍下甜点。凤梨酥是个好东西，特别是台湾李家大房的产品，皮酥馅软，甜而不腻。吃过两个李家大房之后，包你再也不想吃徐福记的烂货。然而李家大房的凤梨酥相当贵，这次去鼓浪屿也正好找到了一个做凤梨酥的店铺。“赵小姐的店”不仅在鼓浪屿赫赫有名，在淘宝上也有人专门代购，想吃可以直接邮购（甜甜的麻糍），邮费相当划算。




上面的照片是赵小姐的礼盒装。总共有四种甜点，每种十二个，分别是蜜柚饼、绿豆饼、红豆饼和凤梨酥。打开的那一盒就是凤梨酥，除了酥皮有点硬之外，其它的地方都挺好。
岛上还有一家咖啡厅也做素饼和凤梨酥，不过名气不是很大。我厚着脸皮把所有的饼都试吃了一遍，酥皮做得比较好，但是味道不如赵小姐家的。在这也贴一下好了~

主流美食就介绍到这，最后再给大家介绍个我喜欢的菲利宾烧烤。




第一个烤的是菲利宾阿姨（站在炉子旁边，当然是被烤了~），第二个是西班牙腊肠，第三个是菲利宾腊肠和鸡脯肉，第四个是秋刀鱼。
菲利宾阿姨中文不太行，英语不错。上一样东西，就问味道怎么样；西班牙腊肠的味道很普通，和杭州的烧烤摊没什么两样；菲利宾香肠超级无敌好吃，我吃了三根；鸡脯肉味道和奥尔良烤翅很像，肉特别特别嫩；秋刀鱼和海边的不太一样，菲利宾阿姨烤的秋刀鱼是湿湿甜甜的，据说别有一番风味。

美食篇就介绍到这里，下一篇准备乱弹鼓浪屿。

本来想预定厦门轮渡的如家，结果被光哥鄙视了一把。考虑到之后的两天将会在鼓浪屿上度过，如家确实不太方便，于是就在岛上的家庭旅馆里面选了一个。岛上最有名的家庭旅馆是“娜雅”，其次是“船屋”和“缘中园”。
娜雅的卖点在于猫，著名的“张三疯”就安家在娜雅。而船屋内的卖点是，房间按照船上的等级进行装修。缘中园的装修也很不错，特别是三人房和豪华房，都是两层的小阁楼。娜雅和船屋需要提前一个月进行预定，而且需要预付定金。缘中园提前两个星期就可以，不需要定金。以下是缘中园三人房的实地拍摄：





杭州到厦门的直达动车D3211很难买到票，公司内网上推荐的票贩子直接把我的电话挂了。咨询了丁原之后，得到一条靠谱的转车路线。
D3111 杭州到福州南 07：45出发
D6211 福州南到厦门 14：17出发
D3111+D6211的路线和D3211是一样的，只是在福州南中转的时候，需要等上一个半小时。不过这点时间刚好下车吃点东西，活动下筋骨。

到了厦门火车站，第一件事就是去动车票窗口买回程火车票。值得注意的是，动车窗口和普通票窗口不在同一个地方！
普通票窗口的队伍超级无敌长，排到底反而买不到自己想要的票，那就直接悲剧了。
D6240 厦门到福州南 12：17出发
D3114 福州南到杭州 14：33出发
路线和来的时候基本一样，熟悉的站台。晚饭时间需要在火车上度过，建议大家买好方便面，因为火车上只卖35元的高价盒饭。

在厦门火车站买好回程票，就可以往港口出发了。
出了火车站，往左斜传马路，可以找到很多公交车直达“轮渡”站，一块钱搞定。路上可以顺便看看老旧的店面和慢吞吞的行人。

到了港口，就要上渡轮了。不要上15块钱的那个游览船，除了浪费40分钟看莫名其妙的海岛之外，还有机会被坑额外钱。省钱的那个船双程是8块钱，上鼓浪屿不需要钱，出来才会收钱。这里严重鄙视一下港口的工作人员，为了钱真是什么都干！

未完待续，下个是“美食篇”。

handlerton提供的是存储引擎的一些特性。比如记录点、提交、回滚。同一个引擎跨表的操作需要在handlerton里面完成，比如说引擎的初始化，跨表的事务。
handler提供了表的基本操作。比如打开关闭表、扫描数据索引，都可以在handler里面找到相应的接口。每个handler的子类进行初始化对象的时候，必须向构造函数传递一个handlerton对象的引用。
handler类有很多纯虚函数，必须要在handler的子类里面实现。这些函数决定了存储引擎的底层io方式，包括数据存取和索引。
ha_example.h里可以很方便地找到这些纯虚函数：
int open(const char *name, int mode, uint test_if_locked); // required
int close(void); // required
int rnd_init(bool scan); //required
int rnd_next(uchar *buf); ///< required
int rnd_pos(uchar *buf, uchar *pos); ///< required
void position(const uchar *record); ///< required
int info(uint); ///< required
int external_lock(THD *thd, int lock_type); ///< required
ha_rows records_in_range(uint inx, key_range *min_key, key_range *max_key);
int create(const char *name, TABLE *form, HA_CREATE_INFO *create_info); ///< required
THR_LOCK_DATA **store_lock(THD *thd, THR_LOCK_DATA **to, enum thr_lock_type lock_type); ///< required

貌似有点困了。改日用GDB调试一下EXAMPLE引擎，再上来写一个~

一个团队的强弱与否，很大部分是取决于团队成员是否有明确的自我定位，以及这个自我定位是否符合团队发展的目标。简单的说，就是个人目标与团队目标的高度契合。淘宝MySQL DBA团队的目标很明确，就是成为国内首屈一指的技术团队。那么如何使得狼和羊都找到自己的位置，使得整个团队力往一处使？值得深思。

对于开发支持DBA来说，核心价值在于了解业务的深度。了解得越深，支持得越好，努力做到防范于未然。避免了问题的发生，那么就可以用省下的时间支持更多的业务，从而得到个人价值的提升。
对于运维DBA来说，最重要的莫过于管理工具自动化。在集中式管理即将成为历史的今天，DBA对系统的话语权正在减少。但分布式架构在解决可拓展性问题的同时也引入了分布式管理的难题，DBA是否能够实现自动化管理，正在成为系统成败新的关键点。另外，不断尝试新的硬件、新的MySQL版本来提升性价比，也是运维DBA的一个重要价值。

充分引导这两种DBA发挥自己的价值，是构建DBA团队的基础。然而MySQL的开源特性，使得MySQL DBA的发展具有更多的选择。
如果能够将自己编写的代码融入到MySQL主干代码里面，在满足公司业务需要的同时回馈开源社区，将一滴水融入永不枯竭的大海之中，那么势必得到各方的认同。

每个人对自己的定位不同，一个好的团队不应该成为个人发展的瓶颈。
如何定位自己，如何帮助别人定位？我需要多花点时间去研究这个了。

读的TPS和响应时间，横坐标为线程数：

Cassandra集群（四台）和MySQL（一台）做了相应的读写对比测试。测试场景是key-value形式的，Cassandra 400w个key，MySQL 200w个key，每个key下存放100个column。column name是时间戳，value是平均长度为0.5k的随机数据。
Cassandra的replica facor是2，InnoDB的innodb_flush_log_at_trx_commit是2。

随机写 Tps 平均响应时间（ms） 最大响应时间(ms)
MysqL 5300 7.42 2562
Cassandra 12000 1.64 3685

随机读 Tps 平均响应时间（ms） 最大响应时间(ms)
MysqL 1010 78.92 1969
Cassandra 1200 68.23 4006

因为测试的时候只是用了一台MySQL，而cassandra使用了四个节点。所以MySQL最终的TPS，写入要乘以2，读取要乘以4。
本次测试的结果中，MySQL的读取性能远远高于Cassandra，而写入微微弱于Cassandra。
这个结果和java代码写入数据的模式有关，不代表MySQL在任何场景下都读取都强于Cassandra。