分布式架构和事务
文章平均质量分 70
西海棱镜
小路天下
展开
-
分布式事务方式
作者:何明璐 链接:http://www.zhihu.com/question/29483490/answer/98237582 来源:知乎首先是不建议采用XA两阶段提交方式去处理分布式事务,要知道要能够支持XA分布式事务,必须是要实现XA规范才可以,而Service本身是无状态的,如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者原创 2016-06-05 10:31:39 · 723 阅读 · 0 评论 -
分布式系统和数据同步要点
1,基础缓存更新应该采用Databus实时同步,Solr采用cancel等工具实时同步,非基础数据采用业务层做同步。2,redis失效用户请求会压倒DB如何处理,A设置不同的过期时间 B对有些数据设置永不过期 C考虑服务降级 D二级缓存本地缓存。3,写库失败,第二部淘汰缓存失败,出现数据不一致,如果先淘汰缓存再DB失败,则会引发cache miss,肯定是先淘汰缓存再写DB,加入1个服务层原创 2016-10-06 16:13:36 · 7105 阅读 · 0 评论 -
分布式DB规划要点
1,划分核心非核心功能,例如游戏的接入业务中,登录注册校验为核心功能,msg和日志为非核心功能,DB,server和cache都需要物理隔离,只要核心非核心存在共享资源,如DB公用1个,要是非核心出现大量整表查询,核心功能会受到影响,核心和非核心之间采用接口访问。2,一张大表拆分到不同DB,来提升数据库性能。DB分为4个分库,模值为1024,每个分库占据256个位置,hash (test123原创 2016-10-06 17:00:48 · 1410 阅读 · 0 评论 -
分布式微服务要点
1,配置dubbo.properties,IP,注册中心,端口(hessia及rest),日志,通知的MQ等Spring配置dubbo,使用zookeeper注册中心暴露服务地址,注解扫描器。发布服务使用dubbo:service interface 或者注解发布。消费服务也有非dubbo环境的消费端,更新pom文件,加入hessia jar,添加hessia协议配置并设置使用hess原创 2016-10-06 22:25:11 · 2588 阅读 · 1 评论 -
电商秒杀系统设计分析
1,乐视秒杀,每秒钟10万的订单更新(insert/update),以用户ID分库分表,二叉树分库扩容,表级同步,DB1 - DB8, order1 - order10, DB编号 = (uid/10)%8,表编号=uid%10,这样单库基本上可以保持1万左右的并发,可以业务层分库分表,也可以使用mycat之类的中间件。订单ID结构:分库分表信息+时间戳+机器号+自增序号分信息:1bit数原创 2016-11-26 00:32:17 · 9516 阅读 · 1 评论 -
支付模块分析
1,一笔订单支付成功,会在第一时间通知,系统收到通知处理逻辑,必然返回1个SUCCESS,第三方接到SUCCESS就不再通知,否第三方支付平台会认为未收到通知,然后再过10s 20s 180s再 通知你。客户端会上传接收通知的接口,定时调用,客户端也要定时去查询,在错过第一次接收后,通知通知,异步通知,支付状态查询。2,认证支付:用户在绑卡时,将卡信息提供给电商,这样在支持时,就无需再原创 2016-11-27 15:18:58 · 3473 阅读 · 0 评论 -
分布式事物处理方式要点
1,柔性事物,二阶段2PC型,补偿型,异步确保型,最大努力通知型。 2PC适合场景:客户账,收费异步确保型:会计性,资金订单,通知数据。核心交易数据分库并分表,消费记录数据分库分表,商户交易数据分库分表。 保持多个维度的数据集群可以使用MQ异步同步,MQ异步也会导致数据不一致,则引入实时监控服务,实时计算2个维度集群差异,作一致性同步。2,事务型原创 2017-04-01 14:19:46 · 5468 阅读 · 0 评论 -
kafka9重复消费问题解决
原文:http://blog.csdn.net/u011637069/article/details/72899915背景:之前用的kafka客户端版本是0.8,近期升级了kafka客户端的版本,写了新的消费者和生产者的代码,在本地测试没有问题,可以正常消费与生产。但最近的项目中使用了新版的代码,当数据量较大时会出现重复消费的问题。现将问题的排除与解决过程记录下来,避免再次踩坑。原创 2017-09-22 11:25:51 · 2471 阅读 · 0 评论