20171115-19问题整理

• 总摘要: 事务. Kafka. 并发. 分布式事务落地. 一致性Hash.

2017-11-15

• 摘要: 事务. Kafka. 并发.

1. 电商的很多业务，考虑更多的是 BASE（即Basically Available、Soft state、和Eventually consistent），而不是 ACID（Atomicity、Consistency、Isolation和 Durability）。即为了满足高负载的用户访问，我们可以容忍短暂的数据不一致。那怎么做呢？

• 第一，不做分布式事务，代价太大。
• 第二，不一定需要实时一致性，只需要保证最终的一致性即可。
• 第三，“通过状态机和严格的有序操作，来最大限度地降低不一致性”。
• 第四，最终一致性（Eventually Consistent）通过异步事件做到。
  如果消息具有操作幂等性，也就是一个消息被应用多次与应用一次产生的效果是一样的话，那么把不需要同步执行的事务交给异步消息推送和订阅者集群来处理即可。假如消息处理失败，那么就消息重播，由于幂等性，应用多次也能产生正确的结果。
  实际情况下，消息很难具有幂等性，解决方法是使用另一个表记录已经被成功应用的消息，即消息队列和消息应用状态表一起来解决问题。

2. 事务消息

杭州–小神(-) 11:49:07
最终一致性适合一致性要求不高的场合。强一致性的，这种就要蛋疼点.
北京-竹竿(-) 11:57:14
@杭州–小神 你们使用的什么MQ
上海-下一秒升华(-) 11:58:33
第六步本地事务提交成功，第七步mq commit失败，这种情况怎么办？
北京-屁颠颠(-) 12:47:07
顺序有要求的吧
北京-屁颠颠(-) 12:47:38
现在基本都是mq 来做补偿事务吧
北京-屁颠颠(-) 12:48:42
自动补偿都要根据自家业务定制的
广州-小护士(-) 12:50:09
所以消息的可靠传输就很重要~

3. Kafka 开放性问题[西神]

• 我有个疑问，kafka种，生产者可以设置· min.insync.replicas，然后broker也可以设置，而且这两个值还可能不一样。比如生产者设置1，而broker设置为2，意思就是生产者认为有一个副本成功就算成功，那broker的意思是要2个副本成功才算成功，那这个不是矛盾了么。还有，生产者怎么知道写入成功，还不是要broker给返回吧，那broker设置的是2，如果2个没写完，它如何返给生产者结果呢?
• 它说如果生产者设置为1，broker设置为2，那么当生产者发送了消息给leader，leader马上就返回说成功，但是此时leader还没同步到副本自己就挂了，此时ISR会选一个成为leader，但是这个leader对于之前发送的消息并不存在，因为之前leader还没同步给它就挂了，这样一来整个集群就丢了消息，而生产者确认为我写入消息是成功的，于是造成了不一致.

• Kafka设计解析（二）- Kafka High Availability （上）
• Kafka设计解析（三）- Kafka High Availability （下）

北京-ylh(-) 20:13:33
不可能100%不丢吧
南京-刘(-) 20:16:17
应该会丢 目前了解的一个系统用的kafka还配套了补偿机制
成都-梅小西(-) 20:16:23
你们在写kafka的时候设置了重试机制么，一般重试几次
北京-屁颠颠(-) 20:18:22
2

4. 对于防止并发，在整个系统中，什么方案比较好点呢？[成都-..累狠久ㄋ(-) ]

成都-..累狠久ㄋ(-) 21:44:07
重复并发，在整个系统中，什么方案比较好点呢？
成都-梅小西(-) 21:44:24
那不就是幂等么
成都-..累狠久ㄋ(-) 21:44:33
就是重复的线程，会造成重复的数据在DB里
上海--小虫(-) 21:44:46
队列
成都-..累狠久ㄋ(-) 21:45:29
比如在数据库集群的情况下又如何处理呢？
成都-献计献策(-) 21:49:33
防止并发？并发为什么要防止？
成都-梅小西(-) 21:49:45
重复数据，要么单线程，要么db做唯一验证
成都-梅小西(-) 21:49:51
要么代码里加锁
成都-..累狠久ㄋ(-) 21:50:08
要做负载均衡，
成都-梅小西(-) 21:50:09
你得举个详细的例子才能帮你
成都-..累狠久ㄋ(-) 21:50:45
就是比如一个接口，要发送销售订单数据，然后防止他提交重复的数据。类似这种把。当然也有从界面新增的数据,如果客户点了两次，那么也可能发生这样的事
成都-梅小西(-) 21:51:48
表里面做了唯一索引么
成都-(-) 21:53:15
点两次这种操作在前端可以限制撒
成都-..累狠久ㄋ(-) 21:53:17
主键默认要采用唯一索引
成都-梅小西(-) 21:53:22
你的意思是，2个应用有可能发送同一条数据进db里？
成都-梅小西(-) 21:53:28
你做了负载均衡
成都-梅小西(-) 21:54:26
这是一种办法
成都-..累狠久ㄋ(-) 21:55:46
但是重复的并发，也会损耗性能的
成都-..累狠久ㄋ(-) 21:56:41
这只能方式重复的DB数据.
广州-后觉(-) 21:57:03
分布式锁
成都-梅小西(-) 21:57:09
db做唯一索引最方便
成都-梅小西(-) 21:57:34
还有种方法，单线程，比如通过mq，或者通过分布式锁
成都-..累狠久ㄋ(-) 21:58:17
分布式锁，太慢啦
成都-梅小西(-) 21:58:22
还有一种方式，db的共享锁，前提条件是需要索引，不需要唯一索引, 这种方式我用过
成都-梅小西(-) 21:58:56
你的详细情况我不了解无法具体帮你
成都-..累狠久ㄋ(-) 21:59:13
嗯嗯，已经帮了很多。我结合实际情况看哈
成都-梅小西(-) 22:02:19
你可以把你的情况把敏感数据去掉然后给我们一个实例，我们才能帮你
成都-..累狠久ㄋ(-) 22:03:06
暂时只是考虑这种情况。还没开发
成都-..累狠久ㄋ(-) 22:04:29
其实在mvc层有个tocken可以解决重复提交
成都-..累狠久ㄋ(-) 22:05:10
对于接口之间的重复并发，还有DB的确实之前不知道
成都-..累狠久ㄋ(-) 22:06:22
但是如果是分库的话，
成都-梅小西(-) 22:07:15
分库没关系啊，同一个订单数据最终会到同一个表啊
成都-梅小西(-) 22:07:27
只要在同一个表，就可以控制
成都-梅小西(-) 22:07:41
再说了，就算不在一个表，也有办法
成都-..累狠久ㄋ(-) 22:08:08
如果不在一个表怎么弄好点呢？
成都-..累狠久ㄋ(-) 22:08:35
如果有4个库，刚好4条重复到4个库中的话，该怎么办呢？
成都-梅小西(-) 22:09:02
那只能走单线程了，比如同样的订单排队
成都-梅小西(-) 22:09:06
不同的订单不用排队
成都-..累狠久ㄋ(-) 22:10:07
怎么操作的呢？
成都-梅小西(-) 22:10:53
分布式锁，同样的订单，比如用订单唯一性字段做key
成都-..累狠久ㄋ(-) 22:10:58
这样就需要判断是否是相同的订单
成都-梅小西(-) 22:11:49
我擦，你不是说了有重复数据么，你用你的重复标准做key不就行了
成都-..累狠久ㄋ(-) 22:12:03
嗯是的
广州-Frank(-) 22:12:08
你这就是幂等，你去查下如何做幂等
杭州-jiwliu(-) 22:12:33
你这是什么应用场景，确定涉及到4个库这么大吗？
杭州-jiwliu(-) 22:13:06
前端可以用一些防止表单重复提交的手段
成都-..累狠久ㄋ(-) 22:13:08
打个比方, 有些数据不走前端
广州-Frank(-) 22:13:18
都不关数据量的问题，他主要是防止重复提交
广州-Frank(-) 22:14:15
你是想说直接调用接口提交吗
上海-中纪委(-) 22:28:32
放在後台做比較好點
深圳-rubin(-) 22:29:22
做幂等就行啦
成都-梅小西(-) 22:33:37
我总觉得前端做重复校验解决不了根本问题
成都-梅小西(-) 22:33:43
确实可以绕过
深圳-rubin(-) 22:34:28
前端不可信
广州-后觉(-) 22:35:06
前端最好也做，后端一定要做
上海--海棠(-) 22:39:40
防止表单重复提交，后端是要做的
深圳-wjc(-) 22:42:07
后端要做这个保护。
北京-liunx(-) 22:42:10
前后都做比较好吧。
深圳-wjc(-) 22:42:19
但是前台肯定也要做啊

2017-11-16

• 摘要: 分布式事务落地 , 一致性Hash

1. 这种分布式事务落地的方案，哪位大佬有落地过吗？

北京-屁颠颠(-) 9:44:40
这种分布式事务落地的方案，哪位大佬有落地过吗？
深圳-山峰(-) 9:46:10
本地消息表可以，但是我们这边现在有点问题，就是本地消息表写太频繁了，读的时候有问题
成都-梅小西(-) 9:47:08
这种方式貌似用的挺多
成都-梅小西(-) 9:47:15
用本地表+消息
成都-梅小西(-) 9:47:26

广州-小护士(-) 9:47:29
用本地缓存写消息，异步写入消息表
北京-屁颠颠(-) 9:50:18
好像这种要不同的业务部门对这个消息表，进行对账，不知是不是这样
北京-竹(-) 9:50:35
对账，是不好些？
成都-OOXX(-) 9:51:54
消息事务表 比如 扣库存 下单 这儿有个事务表
那么 下单后 消费优惠劵这里 又得有个事务表？
深圳-waiter(-) 9:52:03
这里最好应该不要撤销操作 而是重试 [图片上传失败...(image-3ab5da--)]
北京-屁颠颠(-) 9:52:54
这个事务表怎么搞，也不太清楚
成都-OOXX(-) 9:53:33
优惠劵后面 要是再来个加积分或者什么的服务 还得有个事务表？
北京-遇见(-) 9:54:01
B系统往A系统发送消息这种也是走mq?
北京-屁颠颠(-) 9:54:23

聊聊分布式事务，再说说解决方案
北京-屁颠颠(-) 9:55:55
@成都-OOXX 我们也有积分和折扣
成都-梅小西(-) 10:03:25
要么就不要这么复杂，直接走补偿算了
成都-梅小西(-) 10:03:34
凡是没成功的，都记录下来
北京-屁颠颠(-) 10:04:25
本地消息表（异步确保） 这个就是走补偿的
北京-遇见(-) 10:04:38
@成都-梅小西 B系统往A系统发送消息这种也是走mq?
北京-漫游(-) 10:05:49
补偿的话得保证幂等
北京-喜(-) 10:06:58
分布式事务就一定不需要做幂等？
北京-屁颠颠(-) 10:09:26
那个本地消息表，不是为了做幂等的吗？
广州-端茶倒水(-) 10:13:10
有重试吧，跑批

2. 项目中最有挑战的技术点, 一致性hash. 如何保证分布式一致性, 如何跟踪一个请求. etag, lastmodified, perm增长, 如何定位. 讨论. [成都-梅小西]

杭州-小刚(-) 20:19:33
第三个延伸起来东西还是比较多的，可以搞一个链路追踪系统
北京-哇咔咔(-) 20:20:26
一致性哈希我抄的jedis 
北京-哇咔咔(-) 20:21:02
第二个可以用raft 细节记不住
北京-竹竿(-) 20:21:15
其实我想问，一致性hash加节点
上海-给你们(-) 20:21:54
单服务的链路跟踪写通用组件不来就不好写，分布式链路跟踪还是有技术含量的
北京-竹竿(-) 20:21:54
本身没什么好讨论的，加减节点时候 可以讨论
北京-哇咔咔(-) 20:22:13
Trace span prevspan记日志用来追踪
上海-给你们(-) 20:22:41
记日志比较low
北京-哇咔咔(-) 20:22:47
Perm 增长可能是动态类太多，检查有哪些动态类生成了一直没回收
北京-哇咔咔(-) 20:23:13
你们怎么追踪的
北京-哇咔咔(-) 20:24:17
加减节点，重新创建一致性哈希环
上海-给你们(-) 20:25:21
之前接触过一个风控项目，用bcel动态埋点，有些过一些代码
上海-给你们(-) 20:32:38
开发cat的时候写的动态埋点，然后分布式链路这个是衍生的服务，扔es里做链路查询
北京-竹竿(-) 20:34:04
链路跟踪 只有异步遇到线程池值得讨论
上海-给你们(-) 20:34:43
分布式和异步的场景是一样的
北京-竹竿(-) 20:34:52
不一样
成都-梅小西(-) 20:35:16
我有个疑问，设置为自动提交offset，是在拿到消息后会自动提交还是我处理完了这个消息才会自动？
成都-献计献策(-) 20:36:56
业务上消息处理失败，要存下来
成都-献计献策(-) 20:37:05
等待重试
成都-梅小西(-) 20:38:15
你们是自动还是手动
北京-ylh(-) 20:38:30
自动

3. mysql 时间类型存储

2017-11-17

• 摘要: 分布式事务落地 , 一致性Hash

1. 项目使用Mycat分库，在mycat中分为多个schema；是否可以通过MyBatis的Interceptor指定SQL执行的schema？ [北京-java菜鸟-天下]无果

2. 有一场景，监控平台统计，存放日志数据，但各个系统的日志信息格式可能不一样，存量估计在5000W左右，请大家帮忙提提建议. [深圳-安分]

深圳-安分<-> 16:24:27
选 用mongodb可行吗？
北京-wdm(-) 16:25:14
es也可以嘛
成都-勇(-) 16:26:21
感觉ELK就是为你定做的
深圳-心阳(-) 16:48:47
选用mongodb会卡死的，这个适用少量不规则数据。es也可以存放不规则数据啊，只是多写几个实体. 选型ELK(ElasticSearch, Logstash, Kibana)