docs: update doc to fix #128

* close #128 
* thanks @hhqiwei
This commit is contained in:
Yang Libin 2019-11-27 16:56:06 +08:00 committed by GitHub
parent 0fa8278539
commit 45ab02cb7e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -7,7 +7,7 @@
## 面试题剖析
我举个例子,我们以前做过一个 mysql `binlog` 同步的系统,压力还是非常大的,日同步数据要达到上亿,就是说数据从一个 mysql 库原封不动地同步到另一个 mysql 库里面去mysql -> mysql。常见的一点在于说比如大数据 team就需要同步一个 mysql 库过来,对公司的业务系统的数据做各种复杂的操作。
你在 mysql 里增删改一条数据,对应出来了增删改 3 条 `binlog` 日志,接着这三条 `binlog` 发送到 MQ 里面,再消费出来依次执行,起码得保证人家是按照顺序来的吧?不然本来是:增加、修改、删除;你是换了顺序给执行成删除、修改、增加,不全错了么。
你在 mysql 里增删改一条数据,对应出来了增删改 3 条 `binlog` 日志,接着这三条 `binlog` 发送到 MQ 里面,再消费出来依次执行,起码得保证人家是按照顺序来的吧?不然本来是:增加、修改、删除;你是换了顺序给执行成删除、修改、增加,不全错了么。
本来这个数据同步过来,应该最后这个数据被删除了;结果你搞错了这个顺序,最后这个数据保留下来了,数据同步就出错了。
@ -29,4 +29,4 @@
- 一个 topic一个 partition一个 consumer内部单线程消费单线程吞吐量太低一般不会用这个。
- 写 N 个内存 queue具有相同 key 的数据都到同一个内存 queue然后对于 N 个线程,每个线程分别消费一个内存 queue 即可,这样就能保证顺序性。
![kafka-order-02](/images/kafka-order-02.png)
![kafka-order-02](/images/kafka-order-02.png)