从All-In-One到SOA——技术及架构的演进过程(六)

从All-In-One到SOA——技术及架构的演进过程(六)

 

一些技术点

  • 事务

单一数据库的时候,我们比较容易使用程序控制数据库事务,那么当数据库逐渐增加、分库分表的需求越来越多,我们将会面对很多的数据库,这时候使用程序控制 事务就会遇到很多问题,甚至原来很容易的事现在变的有些复杂了(如,当下单后商品减少、订单增加的情况,商品与订单分属不同的服务与数据库)。当然可以采 用分布式事务,但是分布式事务实现复杂、性能损耗大同时分布式事务规范本身有些问题不可避免。

分布式事务经常会涉及到的概念有两阶段提交、一阶段提交、事务补偿等等,可参考相关文档说明了解详细内容。

这里我们要分析一下,使用事务的最终目的是什么?首先想到的是同时成功或失败,再深入分析一下,我们终于明白要的是什么了:数据的一致性,一致性又分为 最终一致、强一致和弱一致三种。那么是不是所有的场景都要求必须要达到数据的强一致呢?显然不是,这需要我们根据实际情况分析(鱼与熊掌不可兼得,这是一 个不使用任何程序控制事务的场景,一个操作先插入从属信息再插入主信息,即便主信息插入失败也不会给用户带来影响,类似这样以空间换时间的方式也未尝不 可)。

数据的最终一致性业界有了很多的解决方案(非事务方式)。
1)使用MQ、Redis进行协调控制从而达到数据最终一致;
2)通过分析MySQL的Binlog达到数据最终一致;
3)根据行业、业务特点自己实现的数据最终一致。

  • 消息队列

在服务化架构中,消息队列的作用时不可替代的。服务化架构的异步通信、流量消峰、跨语言调用、通知协调等等很多功能都会用到消息队列。

在选用MQ时,要考虑一下我们的需求和MQ自身功能是否匹配,超前的使用有时候并不能给我们带来相应的好处,反而可能会成为使用的障碍。

通常使用消息对立,有以下问题需要注意:
是否保证消息顺序;
消息拉取/推送模式有哪些;
水平扩展能力;
实时能力;
消息堆积能力;
监控功能是否完整/是否提供了完善的监控接口;
是否有持久化能力;
down机重启后,是否可以继续消费;
社区活跃度、更新频率;
成功使用案例。

  • 4
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值