|
|||
|
摘要：
在前面三篇文章中，介绍了关于分布式系统中数据一致性的问题，这一篇主要介绍CAP定理以及自己对CAP定理的了解。CAP定理是2000年，由Eric Brewer 提出来的Brewer认为在分布式的环境下设计和部署系统时，有3个核心的需求，以一种特殊的关系存在。这里的分布式系统说的是在物理上分布的系统，比如我们常见的web系统。这3个核心的需求是：Consistency，Availability和Partition Tolerance，赋予了该理论另外一个名字 －CAP。Consistency：一致性，这个和数据库ACID的一致性类似，但这里关注的所有数据节点上的数据一致性和正确性，而数据库的AC 阅读全文
posted @ 2012-10-25 22:45 西北老狼 阅读(180) 评论(0) 推荐(0) 编辑
摘要：
在我的博文里面 关于分布式系统的数据一致性问题(二) 里面主要介绍了数据分布的情况下保证一致性的情况，在第二篇文章里面，我这里提出了三个问题订单系统调用支付系统支付订单，支付成功，但是返回给订单系统数据超时，订单还是I（初始状态），但是此时会员帐户余额100,会员肯定会马上找京东骂京东，为啥不给老子发货，我都付钱了订单系统调用支付系统成功，状态也已经更新成功，但是通知仓库发货失败，这个时候订单是P（已支付）状态，此时会员帐户余额是100,但是仓库不会发货。会员也要骂京东。订单系统调用支付系统成功，状态也已经更新成功，然后通知仓库发货，仓库告诉订单系统，没有货了。这个时候数据状态和第二种情况一样 阅读全文
posted @ 2012-10-25 22:43 西北老狼 阅读(262) 评论(1) 推荐(0) 编辑
摘要：
在分布式系统的数据一致性问题（一）里面，简单的介绍了分布式数据的同步问题，上面的问题比较抽象，在目前的互联网应用中还很少见，这次在通过一个比较常见的例子，让大家更深入的了解一下分布式系统设计中关于数据一致性的问题这次我们拿我们经常使用的功能来考虑吧，最近网购比较热门，就以京东为例的，我们来看看京东的一个简单的购物流程用户在京东上下了一个订单，发现自己在京东的账户里面有余额，然后使用余额支付，支付成功之后，订单状态修改为支付成功，然后通知仓库发货。假设订单系统，支付系统，仓库系统是三个独立的应用，是独立部署的，系统之间通过远程服务调用。订单的有三个状态：I:初始 P:已支付 W:已出库，订单金额 阅读全文
posted @ 2012-10-25 22:42 西北老狼 阅读(168) 评论(0) 推荐(0) 编辑
摘要：
先把问题简单化处理，假设A增加一条记录Message_A，发送到M，B增加一条记录 MESSAGE_B发送到M，都是通过MQ服务器进行转发，那么M系统接收到条消息，增加两条数据，那么M在把增加的消息群发给A，B，A和B找到自己缺失的数据，更新数据库。这样就完成了一个数据的同步。从正常情况下来看，都没有问题，逻辑完全合理，但是请考虑以下三个问题1 如何保证A->M的消息，M一定接收到了，同样，如何保证M->A的消息，M一定接收到了2 如果数据需要一致性更新，比如A发送了三条消息给M，M要么全部保存，要么全部不保存，不能够只保存其中的几条记录。我们假设更新的数据是一条条发送的。3 假设 阅读全文
posted @ 2012-10-25 22:40 西北老狼 阅读(206) 评论(0) 推荐(0) 编辑
摘要：
最近只是一时兴起，觉得无聊，正好要到买票的时候，写了这个一系列文章，首先是对自己这些年来的工作经验的总结，其次是把分布式事务性系统的设计思想进行分析和整理，最后也就是和想集大家的智慧，讨论系统的设计。我不是铁道部的工程师，我只是一家互联网金融类公司的屌丝工程师，级别不高，能力也一般，就是喜欢技术而已。在第二篇文章里面，重点分析了余票库的整体设计，我看到有的评论说了几点，现在整理一下1 为什么要用悲观锁为什么要用锁，由于之前是做金融系统，对数据的一致性要求很高。铁道部的出票操作要保证数据一致性，所以必须在获取余票的情况下锁定余票记录，否则会导致并发问题，多出票。如果是站票还无所谓，如果是卧铺咋办 阅读全文
posted @ 2012-10-25 22:39 西北老狼 阅读(156) 评论(0) 推荐(0) 编辑
摘要：
在上一篇文章中 铁道部信客票系统设计（一） 里面，探讨了关于数据库层面的功能性需求以及非功能性的需求，在非功能性需求里面，一博主 提出了没有考虑到峰值的情况，这一点的确漏掉了，因为我们铁道部的特殊需求，在春运期间负载很大，平时可能一般，如果用考虑最大的情况，则回存在浪费的情况，如果考虑不足，就像网络订票一样，苦逼。就好比 铁道部春运的时候，发车量大，但是如果制造大量列车，平时就空闲了，也就很亏。机器的折旧很是块的。春运期间可以考虑紧急扩容来实现，所以从设计上可以保持这种扩展性。 扩容是一项工程，整体来说比较复杂。上一篇博客发表后，也有博主和我探讨过一些问题，也让我了解到铁道部目前的状态。由于这 阅读全文
posted @ 2012-10-25 22:37 西北老狼 阅读(147) 评论(0) 推荐(0) 编辑
摘要：
这几天正好看到一条新闻铁道部:新客票系统2015年建成 ，正好最近想整理和总结一下这几年的工作中的收获，正好可以借这个机会，尝试设计一下铁路客票系统，把自己所学全部用到这个系统中去，顺便也希望各位猿们拍砖，一起探讨一下设计，技术吗，讨论讨论总是有点收获的，总比一个人在那里看书好。非功能性要求废话不说，这里先脱离系统的整体架构，后续在不断完善整体架构，这里首先讨论的是数据库层面的设计，因为对于整个架构系统来说，数据库的设计是最为关键重要的，数据库的设计好与坏，决定了整个系统的性能，可用性，扩展性。在考虑数据库的设计之前，我们可以先抛开非业务功能的需求，先看看非功能性需求，主要包括1 数据库的类型 阅读全文
posted @ 2012-10-25 22:35 西北老狼 阅读(198) 评论(0) 推荐(0) 编辑 |
|||
