Lazy MySQL DBA

消息中间件（Message Oriented Middleware，以下简称MOM）是什么？
通俗一点说，MOM就像一个快递公司。从发件人那里收取货物（消息），运到收件人那里。

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

整体架构图如下：

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

很久之前看过Understanding MySQL Internals的一些片段。最近很烦，于是又翻了翻（纯发泄）。

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引擎，再上来写一个~

上次那个测试结果，不太令人满意。
api调用的时候，对一致性要求太高，导致cassandra性能下降不少。
于是换了一个哥们来压测cassandra，而且还非常专业得画了图出来。
测试场景就没什么好说了（Cassandra两个节点互备，MySQL单台），直接上结果图好了：
写的TPS和响应时间，横坐标为线程数：

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

Cassandra最近很火爆，有开发兄弟想往上面迁移数据，于是这星期做了MySQL和Cassandra的性能测试。

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。