服务设计要解决的问题

  前几天和同事聊天,同事说:

  “业务的服务(相对于我们基础架构这边的底层技术)在技术上就需要解决三个问题:分布式、通信和存储。”

  我回忆之前做业务的时光,觉得确实,再加上一个“服务治理”就差不多了。想想“服务设计要解决的问题”这个话题可以把之前静儿写的很多文章做一个归纳概括。今天做一个总结。

分布式

通常要解决的问题是分布式事务的一致性问题。

刚性事务和柔性事务

  刚性事务:严格遵循ACID原则(原子性、一致性、隔离性、持久性)的事务。基本上指的是本地数据库事务。根据CAP原则,分布式下的事务都不是刚性事务。

  柔性事务:遵循CAP理论或者其变种BASE理论的事务。分布式事务基本上都是柔性事务。

  因为刚性事务基本上等价于本地数据库事务,而柔性事务基本上等价于分布式事务。只是一个是按照事务严格性来区分,一个是按使用场景来区分。所以平时除了用来做对比,很少直接提刚性事务和柔性事务的概念。

分布式事务理论

  分布式事务:在分布式环境下,各个操作步骤并不在同一台机器上,需要保证所有动作都有一个统一的结果的一组操作。

  CAP原则(记得在之前的博客中多次写过):分布式环境下,数据一致性、服务可用性、分区容错性三者最多只能满足其中二者。

    数据一致性(consistency):这里的一致性是强一致性,又叫线性一致性。即一个写操作成功,而读出的必须是写操作后的新数据。而写操作失败读出的必须是写操作前的旧数据。

    服务可用性(availability):所有的操作在一定时间内都能得到响应。

    分区容错性(partition-tolerance):在网络分区环境下,被分割的节点仍然能对外提供服务。

选    择说    明

AP分隔的节点同时对外服务但不能相互通信,将导致状态不一致,即不能满足C

CP网络分区的情况下为达成C,请求只能一直等待,即不满足A

CA在一定时间内要达到节点状态一致,要求不能出现网络分区,则不能满足P

  BASE理论:这是基于CAP理论权衡之后的结果。核心思想是即使无法做到强一致性,但可以使用一些技术手段达到最终一致。BASE是Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)的缩写。

分布式事务一致性实现方案

  为了解决分布式一致性问题,前人在性能和数据一致性的权衡过程中总结了许多经典的协议和算法。比较著名的有:2PC、3PC、TCC、Paxos、Raft、Zab、ISR。除了这些之外,业界用的最多的其实是基于MQ实现的。

  2PC(Two Phase Commit)两阶段提交:一般说的两阶段提交是基于XA协议的。另外JTA协议的也比较常见。

  XA是一个分布式事务协议。它大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Oracle、DB2都实现了XA接口。MySQL对XA的支持不是很好。而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

两阶段提交的优点是:原理简单、实现方便。缺点是同步阻塞、单点问题、数据不一致。

  3PC(Three Phrase Commit)三阶段提交:分为CanCommit、PreCommit、Do Commit 三个阶段。就是把两阶段提交的Phase 1分成两个,预提交的时候如果有参与者返回No或者超时则中断事务。

  三阶段提交的优点是降低参与者阻塞范围,并能够在出现单点故障后继续达成一致。缺点是因为preCommit阶段,在这个阶段如果出现网络分区,协调者无法与参与者正常通信,参与者仍然会进行实物提交,造成数据不一致。

  TCC(Try-Confirm-Cancel)

    Try:完成所有的检查,预留必须资源

    Confirm:使用Try阶段预留的资源执行业务,如果执行出现异常,要重试

    Cancel:释放Try阶段预留资源

    TCC能够对分布式事务中的各个资源进行分别锁定,分别提交与释放。适用于严格一致、执行时间短、实时性要求高的场景。

  Paxos算法:之前看过《从Paxos到Zookeeper》那本书,没怎么看明白。实现比较复杂,Zookeeper就是用这个来实现的分布式一致性。Paxos算法、Raft协议和Zab(Zookeeper Atomic Broadcast)协议都是一种通过多数投票来保证主备数据一致性的。

  ISR(In-Sync Replicas)机制:Kafka使用了这个机制来保证数据一致性。ISR认为对于2f+1个副本来说,多数投票机制要求最多只能允许f个副本发生故障,如果要支持2个副本的容错,则需要至少维持5个副本。

通信……

关于作者

静儿,20岁时毕业于东北大学计算机系。在毕业后的第一家公司由于出众的语言天赋,在1年的时间里从零开始学日语并以超高分通过了国际日语一级考试,担当两年日语翻译的工作。后就职于人人网,转型做互联网开发。中国科学院心理学研究生。有近百个技术发明专利,创业公司合伙人。有日本东京,美国硅谷技术支持经验。目前任美团点评技术专家(欢迎关注静儿的个人技术公众号:编程一生),心法文章可参考我的《自动化管理之新人培养》

技术交流可关注我的github:https://github.com/xiexiaojing

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

看我如何发现Twitter任意账户发送推文漏洞并获得7560美元赏金

在参与Twitter漏洞赏金项目的过程中,我通过一些安全测试发现了Twitter存在的重大漏洞:攻击者不需要获取他人账户权限,就能以任意账户发布推文。我于201...

2579
来自专栏python开发教学

Oracle与Sql server的区别 一直搞不明白Oracle数据库和sql server的区别,今天我特意查资料把他们的区别整理出来

Oracle数据库:Oracle Database,又名Oracle RDBMS,或简称Oracle。是甲骨文公司的一款关系数据库管理系统。

1193
来自专栏微服务

浅谈微服务基建的逻辑

这篇文章主要目的是面向初接触微服务的朋友简单介绍微服务基础建设所需要的各个模块以及缘由。 起点 首先,我们得有一个“服务”。根据定义,我们可以把每个服务实例都视...

39810
来自专栏沈唁志

GitHub代码托管平台提交代码时emoji表情的使用

2034
来自专栏安恒信息

安恒信息明御APT攻击(网络战)预警平台全新升级

安恒信息明御APT攻击(网络战)预警平台V2.0.22升级版已于今日发布,相对之前的版本检测度更加细化,灵活度有了更大的提升,自定义方式也更加人性,...

5875
来自专栏ThoughtWorks

浅谈微服务基建的逻辑 | 洞见

这篇文章主要目的是面向初接触微服务的朋友简单介绍微服务基础建设所需要的各个模块以及缘由。 起点 首先,我们得有一个“服务”。根据定义,我们可以把每个服务实例都视...

3585
来自专栏Guangdong Qi

iOS APP版本构建版本无效

2243
来自专栏Python中文社区

用Python把告警日志发到微信上

專 欄 ❈RaPoSpectre,Python中文社区专栏作者。 网站:www.rapospectre.com❈ 前言 笔者所在公司项目的告警信息会通过钉钉发...

7319
来自专栏知晓程序

好消息!小程序可关联 50 个公众号了!

下面,知晓程序(微信号 zxcx0101)带大家看看,微信官方给大家带来了什么「夜间好消息」。?

882
来自专栏smartguys

(五):C++分布式实时应用框架——微服务架构的演进

版权声明:本文版权及所用技术归属smartguys团队所有,对于抄袭,非经同意转载等行为保留法律追究的权利!

5374

扫码关注云+社区

领取腾讯云代金券