CAP理论
作为web开发人员必须需要知道理解CAP理论。
CAP理论:一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。
Consistency 一致性
一致性指“all nodes see the same data at the same time”,即所有节点在同一时间的数据完全一致。
一致性是因为多个数据拷贝下并发读写才有的问题,因此理解时一定要注意结合考虑多个数据拷贝下并发读写的场景。
对于一致性,可以分为从客户端和服务端两个不同的视角。
客户端
从客户端来看,一致性主要指的是多并发访问时更新过的数据如何获取的问题。
服务端
从服务端来看,则是更新如何分布到整个系统,以保证数据最终一致。
对于一致性,可以分为强/弱/最终一致性三类
从客户端角度,多进程并发访问时,更新过的数据在不同进程如何获取的不同策略,决定了不同的一致性。
强一致性
对于关系型数据库,要求更新过的数据能被后续的访问都能看到,这是强一致性。
弱一致性
如果能容忍后续的部分或者全部访问不到,则是弱一致性。
最终一致性
如果经过一段时间后要求能访问到更新后的数据,则是最终一致性。
Availability 可用性
可用性指“Reads and writes always succeed”,即服务在正常响应时间内一直可用。
好的可用性主要是指系统能够很好的为用户服务,不出现用户操作失败或者访问超时等用户体验不好的情况。可用性通常情况下可用性和分布式数据冗余,负载均衡等有着很大的关联。
可用性分类 | 可用水平(%) | 年可容忍停机时间 |
---|---|---|
容错可用性 | 99.9999 | <1 min |
极高可用性 | 99.999 | <5 min |
具有故障自动恢复能力的可用性 | 99.99 | <53 min |
高可用性 | 99.9 | <8.8h |
商品可用性 | 99 | <43.8 min |
Partition Tolerance分区容错性
分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”,即分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性或可用性的服务。
高并发解决方案思考
接上篇,上次记录整理了网络上的一些解决方案和我自己的理解,最后选择单进程单线程的解决方案。最近再次思考高并发问题,发现了一些问题。
首先,我能接受的方案是单进程单线程的处理逻辑和使用多进程分布式锁这样的机制。
单进程单线程模式
优点
- 顺序执行,保证原子性。
- 复杂度低,不会有进程/线程间通信,锁等问题。
- 调试方便。
缺点
- CPU只能利用到单核,浪费CPU性能。
- 单机毕竟有极限,到达极限,可用性低。
- 可扩展性差。
使用单进程单线程模式需要考虑
- 并发量达到一定量之后,扩展的话怎么办。
- 服务宕机怎么办。
解决方案
- 只在处理需要强一致性数据时候再采用。保证逻辑简单,提高并发量。无关一致性问题可以使用正常的web开发模式。
- 并发量大的话,可以采取分流措施。比如,数据分片,这样可以开启多个单进程单线程的服务处理不同分片的数据,提高并发。
分布式锁
优点
- 可以分布式部署,符合web开发的主流思维,并发高就加机器。
- 高可用。
- 机器利用率高
缺点
- 需要获取锁和释放锁,提高了性能消耗
- 产生死锁
- 复杂度高,编程需要注意的多
- 调试困难,bug复现困难
解决方案
其实分布式锁,只是把多进程多线程强行排队变成单进程单线程,让其排队串行处理,最终保证顺序执行。
解决方案下一篇来写,需要说的很多。
CPA理论来自http://www.hollischuang.com/archives/666
上一页 编程习惯
下一页 php Curl遇到的坑