- 老师在讲订票系统的时候，一开始说我们会牺牲一定的availability和一定的consistency，然而到系统设计完也没领悟是牺牲了什么availability和什么consistency…… 这里好像CAP都满足了啊？
- 其实关于可用性我也有一定疑虑，CAP的A是说必须一直可用吗？还是5个9之类的？这个对具体系统设计面试的意义是什么（比如我这道题知道了会牺牲一定availablity但我在之后的设计中也不需要体现出来；又比如instagram，我知道CAP里可以compromise的是consistency，但我实际设计过程中，也并不是因为我想到了CAP才把系统设计的不强一致的啊）
- Transaction Manager (or namely WatchDog)的具体形式是什么？是一个自己实现的microservice吗？还是一个server，然后TicketService, TransactionService和PaymentService的机器上启动一个TransactionManagerClient？
- 想确认一下，dataflow里具体需要强一致的部分是[第三方Payment, Update TransactionDB, UpdateTicketDB]这三步吗？也就是说这三步需要用2PC manage?
- 监控警报里有一项是data consistency， 这个具体是什么metric…是说进行了X次transaction有Y次一致？
谢谢！
- 都满足是做不到的，考虑订票的情况，我们提前把一张票留下不让其他人定，这样可以允许我们在之后的一段时间内在系统中有一定的不一致，只要我们在这张票状态最终变成卖出还是重新上架的之间把系统变一致就好。
- 比如说 2-phase commit 就是牺牲了可用性来保证一致性
- 实现上我倾向于用 microservice。如果用其他服务器上的 daemon 来实现的话，这些 daemon 两两都需要互相 call 不太合适。
- 是的，可以用 2PC 也可以用 Saga，我会觉得 Saga 好一点，因为有一个第三方付款 API，我们不容易控制 rollback。
- 你说的这个可以，主要是监控 inconsistency rate 在很低的范围，并且 inconsistency 发生之后在很短时间内修正了。
1 个赞
谢谢罗老师！
关于2， 如果2PC的partipant是stateless的，可以autoscale，coordinator使用consensus protocol之类的，2PC就是高可用了吗？又比如一个master-slave数据库系统，如果要求写数据的时候master和slave都写完再返回(block读），这时候 可用性和partition-tolerance（因为有replica)也满足了，一致性也满足了不是吗……
而且还是像我原帖问了，不太明白知道了CAP具体怎么用于设计一个系统。
关于2， 如果2PC的partipant是stateless的，可以autoscale，coordinator使用consensus protocol之类的，2PC就是高可用了吗？又比如一个master-slave数据库系统，如果要求写数据的时候master和slave都写完再返回(block读），这时候 可用性和partition-tolerance（因为有replica)也满足了，一致性也满足了不是吗……
而且还是像我原帖问了，不太明白知道了CAP具体怎么用于设计一个系统。
还有两个其他问题：
-
后面说waitlist service会跟客户端建立session（这里session应该是指websocket吧）, 买票成功后可能notify。如果是手机端的话可以直接用push notification通知吗？push notification和websocket有什么tradeoff
-
上课问过了为什么waitlist 要单独用一个service和一个database，老师说不是streaming data，所以不用kafka。我理解kafka里面一般存的是任务或者日志，但也可以存数据吧，这里既然就是一个queue，kafka也可以persistence，就用kafka存这个排队订票的信息不也是极好的吗？
谢谢！
2PC 的 participant 一定是会产生状态变化的，否则就没有必要在 2PC 里了，一个 participant 一旦本身就是一个分布式系统的时候，它的内部又会有不一致性的问题。这个 autoscale 是不成立的。考虑 transaction 的时候要非常小心。
master-slave 数据库的情况，多台机器下的 master slave 组合，有可能在写到 master 以后宕机，slave 和 master 就会出现不一致，所以是不满足 consistency 的。
CAP 这个原理告诉我们的是这三点没法同时满足，是个取舍，仅此而已。
-
这要看需求。我们说的 tradeoff 都是技术上的 tradeoff，具体用 push notification 还是 websocket 是个产品问题。 websocket 只能做到用户在线的情况下传递消息，而 push 可以在用户没有开 app 的情况下用。
-
这里的 waitlist 逻辑是 - 有多件相同商品，让排队排在最前面的人的来买，如果没有成功再把机会留给后面的人。每件商品存一个 list of users 就好了，用 Kafka 没有什么额外的好处，就简单用 DB 存一下就好。
老师 我想请教一下第4点，“因为有一个第三方付款 API，我们不容易控制 rollback。” 如果saga的话 我们是通过compensatable transaction 实现的退款吧？ 这个和rollback的实际区别在哪呢？
如果要支持 2PC，外部服务需要支持一个 Prepare, Commit, Rollback 的功能。而 compensable transaction 只需要支持一个 Rollback。之前说的第四点表达的不是特别清楚，我的意思是外部的 API 不容易支持这一系列的功能。
谢谢老师 还想问下 一般第三方付款API都会提供rollback的功能吗
第三方支付会提供 payment 和 refund API。可以用来实现 rollback.