总摘要: 读写分离. mysql RR
2017-12-11
- 摘要: 读写分离. mysql RR.
1. 你们数据库做了读写分离吗? 做读写分离，什么情况下要做读写分离呢? 你们判断是否要读写分离是怎么判断的? [上海--海棠]
广州-小护士<-> 9:14:03
读写分离看场景.
Netflix的场景：
多数据园区，需要园区之间高度同步。需要写同步很快的数据库
于是选择了写最快的Cassandra, Netflix是面向全球服务的场景.单单是美国就有至少两个园区，东区和西区. Cassandra出名的读很慢, 所以使用了 Memcache.
成都-梅小西(-) 9:16:34
读写分离一般是高并发系统优化的第一步
北京-天空<->
@上海--海棠 加缓存，简单粗暴
广州-小护士<-> 9:17:23
高并发是个相对概念
上海--海棠(-) 9:17:31
日订单数量10万算不算
广州-小护士<-> 9:17:41
用户请求数 比 接受请求的线程总数
成都-梅小西(-) 9:17:52
10万要看是不是集中在某几个小时, 如果是分散的，还算不上高并发. 读写分离是大部分系统优化的第一步。这只能暂时解决, 往后光靠读写分离是不够的.
上海--海棠(-) 9:22:53
现在我们系统在搞优化，没什么经验
广州-小护士<-> 9:23:06
Netflix栈：
Cassandra， 写快读慢。解决需求：多数据园区高频同步。
Memcache，读快写快，缓存技术。解决需求：Cassandra读慢。
之所以用Memcache 而不用Redis，是由于背后应用架构的选择：微服务，粒度过细的服务.
广州-小护士<-> 9:24:47
我还有个案例，我还记得的，交通银行。
成都-梅小西(-) 9:25:48
交通银行怎么了
苏州-winylee(-) 9:26:02
直接写Memcache，数据会不会丢失
北京-天空<-> 9:26:07
在数据库访问这层加缓存@上海--海棠 ，一层不够再加一层
广州-小护士<-> 9:26:19
交通银行栈：
DB2，历史的选择。写慢读慢，但是够稳定，几十年没出事。
Gemfire，NewSQL，当做缓存。解决需求：DB2写慢读慢的缺点，采用定时异步更新data到DB2
成都-梅小西(-) 9:26:43
缓存用gemfire？这玩意好用么
广州-小护士<-> 9:26:55
为什么选择Gemfire。场景：
网络支付，实时转账，给DB2带来很大的压力. Gemfire是Pivotal家的东西。要收费。
杭州－东子(-) 9:26:53
加缓存吧, 读者分离先别考虑了
成都-梅小西(-) 9:28:30
我的意思是gemfire跟redis，mem这种相比，是不是更牛逼, 招行的技术栈呢
广州-小护士<-> 9:29:15
Gemfire提供了类SQL的查询引擎
广州-Ryan(-) 9:33:55
读写分离和缓存解决的问题都类似，带来的问题也同样，比如数据一致性，业务上容忍不？出问题的兜底方案怎样？
想清这些问题就好下手
2. 问个问题，MySQL RR 解决了幻读？[杭州-微笑]
广州-天道(-) 10:12:15
mysql RR解决了幻读的
杭州-微笑(-) 10:14:07
好像并不完全？
比如A 事务先查一次，然后B 事务插入一条记录，A 事务更新该记录，然后再查一次，此时读到了这条新插入的被更新的记录。
成都-凌落(-) 10:15:56
RR通过 多版本管理解决了幻读问题的
深圳-Foxleg(-) 10:16:28
事务已经遇到平顶了， 继续打通任督二脉啊。
成都-孤狼(-) 10:16:31
你这个问题问的，你先去看看RR
杭州-微笑(-) 10:17:53
RR 不就是读到的一行数据不变吗
北京-Shenandoah(-) 10:18:34
开启事务之后， 其他会话对数据库的操作，让当前会话不可见。
成都-凌落(-) 10:18:46
发现有写操作 读操作 看到的就是历史版本
杭州-微笑(-) 10:20:56
更新操作操作的是select 操作没查到的数据，更新完，select 里多了，不是幻读吗
上海-coty(-) 10:22:04
你可以自己尝试下嘛。
上海-coty(-) 10:22:09
比这样问好多啦。
北京-Shenandoah(-) 10:22:14
好好搜索一下，建议使用Google
杭州-微笑(-) 10:23:25
试验过了
杭州-微笑(-) 10:23:30
我就问问，这个算不算幻读
杭州-微笑(-) 10:25:11
左边A 事务，右边B 事务，A 事务先做了select，B 事务提交之后，A做了左边的操作
成都-梅小西(-) 10:26:02
@杭州-微笑 不会的啊。rr下a还是读的老数据，不会读到b数据
上海-coty(-) 10:26:14
commit 事物不是已经提交啦么 ？
成都-梅小西(-) 10:26:32
他没说a提交啊
上海-coty(-) 10:27:05
a也没读到b的修改啊
杭州-微笑(-) 10:27:14
b 做了插入
杭州-微笑(-) 10:27:32
a 更新了这条插入的数据，再查就查到了
成都-梅小西(-) 10:28:17
a都没查到b插入的时候，如何更新？
成都-梅小西(-) 10:28:20
数据
杭州-微笑(-) 10:29:17
b 插入了id 14 的记录，a 直接更新id 14 的数据，然后再查就查到了
杭州-光明消逝(-) 10:30:18
这个不是数据库事务基础么, 无非就是时间节点, 查询,其它事务提交 (再查询可以查到14,但忽略了),然和14提交
成都-梅小西(-) 10:31:04
你自己试过么, 你设置了不要自动提交么
杭州-微笑(-) 10:32:18
截图是我实验的结果,都是事务中操作的, A 那边提交完再查又不一样
杭州-小五(-) 10:34:16
意思是：首先你得关闭自动提交，再实验
杭州-微笑(-) 10:37:03
回头试试，不过直觉和这不会有关系
成都-梅小西(-) 10:38:56
我靠，当然有关系啊，你没设置关闭自动提交？
上海-coty(-) 10:41:00
必须有关系啊
上海-coty(-) 10:41:06
rr 讲的是在一个事物内啊
杭州-微笑(-) 10:44:11
取消事务自动提交的结果一样
杭州-海妖(-) 11:09:31
mysql RR用gap lock解决了幻读的问题
深圳-scaler(-) 11:15:16
你这个B的插入事务都提交了，A当然能看到了
杭州-微笑(-) 11:15:48
更新前，是看不到的
成都-梅小西(-) 11:16:15
@深圳-scaler 胡说。这是rr。b就算提交了，a也看不到
杭州-微笑(-) 11:16:31
是的
2017-12-13
- 摘要: zk选举. 问题排查.
1. zk 选举机制有哪些缺点？zk选举的羊群效应具体是怎么样子的？[广州-小护士]
广州-小护士9:56:49
但是我不明白里面说的receive notification，那么谁去通知 leader failed？为了避免羊群效应，整个zk集群节点构成一个双链链表。leader failed 了 谁去通知 leader的next node。让这个next node 去执行 getChildren 从而拿到全部children list ？同时又是怎么保证这个通知可达?
杭州-微笑(-) 10:03:00
是监听
广州-小护士<-> 10:03:09
是不是还有一个类似 monitor的节点但并非是zk集群中的成员, 这个monitor会轮询监听那个leader是不是failed了
杭州-微笑(-) 10:03:16
后一个节点监听前一个, 一个节点变化只会引起后一个节点的动作. 那个curator 里的工具算法是这样的.
北京-Mr.Win(-) 10:05:20
我只是建议所以反问你，学东西就应该自己多问问自己，然后再对比一下别人怎么做的，特别是你有疑惑的时候
广州-小护士<-> 10:31:03
zk 集群会有脑裂问题吗
成都-苏连云(-) 10:31:10
不会 , 选举 n/2+1个才能成为leader
北京-天空<-> 10:31:28
会有脑裂啊
广州-小护士<-> 10:32:10
出现脑裂，如何处理？n/2+1 election，然后呢?
成都-苏连云(-) 10:33:58
如果集群一半宕机,选举不出来leader的
成都-梅小西(-) 10:36:24
那就直接宣告集群挂掉, 可以参考下redis哨兵的选举
广州-小护士<-> 10:40:38
没看到哪里文档有说zookeeper集群挂一半然后不能找leader. quorum 是法定人数，这个人数就是刚才说的 n/2 + 1 ？不满足条件就取消 leader activation，然后重新选举？
2. 请问一个面试问题, 没有任何日志的前提情况下, 怎么排查服务器上一个 Java 应用为何莫名其妙的挂掉了呢？ [广州-John]
广州 - Cyan(-) 13:16:40
没日志 看个啥 . 都是说空话，瞎猜
广州-John(-) 13:17:49
嗯 这种感觉 Linux 应该多多少少会留下点蛛丝马迹,Nginx Tomcat Java 这些都没有任何的 log
深圳-wjc<-> 13:42:22
没日志应该不是查把。。。应该是猜。。。
广州-John(-) 13:43:33
嗯 当时有点蒙 但是后面觉得可以结合 Linux 和 监控 可以反查
广州-小护士<-> 13:56:53
实际上, john遇到的问题需要充另外一角度去解决，有点像黑客思维
广州-小护士<-> 13:57:24
如果那个进程有对外访问服务的, 可以查对应消费者的日志, 假设那个进程有被消费者定时轮询访问的，可以尝试查查那个消费者的日志
广州-小护士<-> 13:59:17
如果宕掉的进程本身是在docker 容器环境下运行的，可以查查docker自身的容器日志, 感觉考察的不是纵向思维，而是发散性思维，考察对各种情况的可能性，有点像 detect
广州-Ryan(-) 14:00:49
都是侦探，服务器不挂，进程没有了，先查服务器日志，比如被oom killed了。
如果没有，看看有没办法看命令操作日志，比如人为的kill。
上海-story(-) 14:03:00
我想问下 面试官后面给出答案了吗
广州-John(-) 14:03:09
没有
网友评论