分布式系统是“小米加步枪”的集合
2008年阿里发起了去IOE运动,也就是我们说的IBM小型机、Oracle数据库和EMC存储设备。
当时我在工作的时候听到这个消息,想当然的理解为这是因为这些厂商的东西太贵了。
那么随着后来我对分布式系统的逐步理解,除了贵的原因,除了单机性能无法突破摩尔定律的约束。还有一个重要的原因,就是解决了大规模软件系统的开发效率和开发成本的问题。
怎么解决的。
现在我们都知道了,一个大的单体应用是没有办法快速迭代发布的,编译、测试、发布这些动作一气呵成,在庞大的单体环境里面无法做到。分布式系统集结了众多服务节点,就很容易得解决了不同版本,不同功能快速发布的问题。
我们常说微服务的主要目的是为了更快的开发节奏,就是因为微服务也是分布式系统。需要注意的是,反过来,说分布式系统是微服务系统则是不对的。这个问题,你可以自己思考一下。
另外一个,是成本。
分布式系统环境里面,各个服务节点都可以是廉价的PC机,当然不差钱还可以上更好的设备,数据库也可以是开源的MySQL,然后通过网络把它们连接在一起。
说分布式系统是“小米加步枪”的集合,从硬件成本上来说也不为过。
分布式锁最关键的一环是存储
实现一个锁的功能,最根本的必要条件之一是要有一个存储,然后大家都去这个存储这里拿东西,这个时候你用“权利”维护好这个存储:谁能获取,谁不能获取。
这样锁的基本功能就有了。
环境不同,存储的介质也不同。
单进程多线程,用线程可以共享的内存,直接说就是用一个整数。
单机器多进程,用进程可以访问到的共享内存。
多机器多进程,就要考虑额外的一块地方来存储,Redis、etcd等都是可选项。
问题1:一般来说,一个分布式锁服务,它的正确性要求越高,性能可能就会越低。你认为这个说法是对还是错误,可以举个例子吗。
这个说法是正确的。
由于部分失败和异步网络的现实问题,分布式锁是没有办法达到100%正确性。如果要举个例子的话可以对比zookeeper、redis。
高可用选etcd、zk,高性能选Redis。
问题2:什么情况下会发生客户端以为没获取锁,但锁服务已经颁发锁了?若响应超时客户端不会返回error给锁服务让这次获取锁失败吗?
比如,锁服务的逻辑颁发锁成功,但是通过网络到客户端的时候发生丢包,还没有重试的时候,客户端已经超时了,或者是客户端已经收到锁,但是响应发送到锁服务的时候超时了。
对于锁服务来说,它不能区分超时是发生在客户端收到锁之前还是锁之后。
CAP理论是让我们三选二吗
大多数情况下,我们说的可用性,是指的系统的可用性,一致性,是指的数据的一致性。进而,这里的可用性我们又想追求100%,一致性又想追求强一致性。
CAP 理论给我们定义了系统的设计边界,虽然想要设计出超过边界的系统是徒劳的,但是我们却可以无限逼近边界,并且把它作为我们设计系统的目标。
问题3:CAP理论是让我们三选二吗?
说三选二,严格意义上不对,因为这种说法的言外之意,是要放弃第三个。
肯定不是这样。
由于分布式系统所处的网络环境所固有的特性,延迟、丢包等。是的,我们只能保证CP或者AP两个,但是并不意味着我们要放弃第三者,而是要尽量保证第三者。
如果说是三选二的话,言外之意,好像是要放弃一个。这就不对了。
负载均衡的核心是公平性
分布式系统环境下,会有很多个被称为后端服务的服务,客户端向那么多端额后端服务发送请求,到底该往哪里发送,这正是负载均衡要干的事情。
每一个后端服务的机器性能,可能存在差异,性能好的机器是不是要多承受点流量,性能不太好的机器是不是就可以减轻些负担。
是的,负载均衡在保证“雨露均沾”的同时,还要保证服务实例之间的公平性,不能“欺负”性能不好的机器。
怎么做呢。
我们以采用轮询机制的负载均衡来看,轮询是最简单的负载策略了。
这个时候,我们只需要加上权重就可以,彪悍的机器,权重高些。这样,我们就可以利用权重机制来解决服务实例处理性能差异的问题。
来保证负载均衡的公平性。
----END----
这里记录,我每周碰到的,或想到的,引起触动,或感动的,事物的思考及笔记。不见得都对,但开始思考记录总是好的。
欢迎分享、点赞、在看,一键三连