春节策划第1期 | 分布式金融系统知识，你掌握了多少？

2021-02-12 任杰

分布式金融架构课

进入课程



讲述：任杰

时长03:44大小3.43M



你好，我是任杰。
今天是大年初一，首先祝你春节快乐，身体健康。专栏的正文部分已经结束，相信这几个月的时间，你已经学到了很多。为了让你过节期间能够轻松一些，同时也能巩固之前所学，这个春节假期，我一共为你安排了 3 期特别策划的内容。
今天是策划的第 1 期，我从之前学的课程里精选了一些知识点，给你出了这一套测试题，帮助你检验学习成果。客观题的答案和解析，你在测试后就能直接看到。主观题我暂时不公布答案，给你留下一定的思考时间。
第 2 期我会为你整理一份我的推荐书单。
第 3 期，我会公布主观题的参考答案。有必要的地方，我也会说明对应前面课程的哪一节课，方便你查漏补缺，根据需要去复习巩固相关内容。
好了，那今天我们就先牛刀小试，通过测试题来练练手吧！
首先我给你出了 10 道客观题，5 道多选，5 道单选，你可以点击文稿中的答题按钮进入测试。
完成客观题之后，这里还有两道主观题在等着你。金融系统的特点是要求高，所以当你学会了如何解决金融行业的问题之后，其他行业的问题也就是手到擒来的事了。所谓它山之石可以攻玉，我们来看一看下面这两道其他行业的经典问题。
春运卖票
除了支付以外，技术圈还有一个广为人知的高难度系统是卖火车票。你可以从 2020 年初的这个新闻片段感受以下技术挑战的难度：
今天起，全国铁路开始在 12306 网站发售 2020 年 1 月 23 日，也就是农历腊月 29 的车票，节前售票高峰即将度过。自本月 12 日春运售票启动以来，全国铁路已累计发售车票 1.75 亿张，每天的发售量都在 1000 万张以上。
下面是 2020 年初另外一篇新闻的片段：
2020 年春运期间，12306 在高峰日网络点击量高达 1495 亿次……也就是说，12306 在高峰日平均 1 秒就要承受 170 多万次点击……作为对比，2019 年淘宝的订单创建峰值，是 54.4 万笔 / 秒。
这篇新闻也提到了售票业务的复杂度：
而 12306 的特殊性在于，火车票是一种动态的 SKU，计算起来的数据量可能是普通电商产品的数百倍。
以北京西到深圳福田的 G71 次高铁为例……从北京西站始发的车票，后面有 16 个车站，即 16 种不同的车票；涿州东站是第二站，有 15 种不同的车票，以此类推，单以上下车的站来计算，G71 次高铁就会有 16+15……+2+1=136 个 SKU，而每种票对应 3 种座位，一共是 408 个商品。
以上只是 SKU 的减值。若旅客购买的是短途票，如北京西站到涿州东站，则在 SKU 减去 16 的同时，还要增加涿州东站到之后各站、之后各站相互间的 SKU，即增加 120 个 SKU。若再叠加当前的选座功能（A、B、C、D、F），计算数量可能还要再翻倍。
12306 有雄厚的资金，因此可以选择一些特殊的软硬件方案来解决卖票的问题。作为一个金融系统背景的人来说，你应该如何分析这个春运卖票的问题呢？
王者荣耀《王者荣耀》是由腾讯游戏天美工作室开发并运行的一款 5V5 手游。一个完整的游戏有很多功能部分，比如聊天室、支付系统、电商等等，在这里我们主要研究一下最核心的玩游戏的功能。
常见的游戏设置有 10 个客户端。每个客户端会控制自己在游戏里的角色。所有 10 个角色都在同一个虚拟竞技场内交互，因此每个人都能实时看到其余 9 个角色实时的情况，比如位置、血量、技能等等。
手机玩游戏有一个不好的地方是信号不稳定。当手机信号不好的时候会出现掉线的情况。如果你掉了线，在别的玩家眼里，你一直站着不动，在你自己的眼里，所有其他人都站着不动。但是一旦你手机连上了线，系统马上会恢复到其他 9 个人当前的情况，你还可以继续参与这场还未结束的比赛。
在极端情况下，如果游戏崩溃重启了，你会发现自己依然能进入到原来的游戏，只是加载时间稍微长了一点而已。
那如果按照我们介绍的架构设计思路，你应该怎么设计游戏的前端和后端呢？
欢迎你在评论区分享你的思考和分析，主观题答案我会在大年初四的第 3 期春节策划里公布，敬请期待！

提建议

21 | 容灾（下）：如何通过混沌工程提高系统稳定性？

春节策划第2期 | 读书如抽丝，为你推荐一些我读过的好书

 写留言

精选留言(2)

小动物

2021-02-12

春运卖票

首先，先聊操作类的行为，主要就是购票。
对于购票人而言，关心的是购票结果，对花费的时间有一定的容忍度。
当用户发起下单，那说明一定选择了某辆车。那么就是购票人对某两车的票进行操作。在保证正确性的情况下，第一反应就是队列，所有对同一辆车的购票行为丢进同一个队列中，顺序处理。同一班车虽然因为不同岂止站导致车票组合情况很多，但实际票的数量固定，且数量级并不大。若真的因为购票人数多，排队过长，也问题不大，因为票很容易就卖完。后续的人不需要处理了。
从这个方案出发，服务器可以按车次来配置路由，保证热门线路。

对于查询。在没有查询换乘方案时，查询结果的数量并不多。且查询时应该可以接受一定的错误，毕竟查询和实际下单有时间差，票数量差个几张问题不大。那可以做一定的缓存保证查询。

王者荣耀

玩家每一个操作可以看成一个命令。后端可以按事件溯源架构来设计。在断线恢复后，将断线期间的事件同步至本地，恢复玩家状态即可。

展开



 1
tt

2021-02-16

老师过年好，祝您新春快乐！

对于第一个主观题，我是这么思考的。

首先，火车票动态SKU是12306的核心域，应该花很大的成本去改进，就像课程所说，12306也有雄厚的财力可以去解决，但是有啥特殊的硬件，我还不知道。这里就从咱们课程主要涉及的数据处理的视角出发去思考。

其次，购买火车票的过程主要涉及的是交易数据，应该使用关系性数据库处理最核心的交易环节。

最后，火车票售票张数绝对量很大（全国铁路已累计发售车票 1.75 亿张，每天的发售量都在 1000 万张以上），交易并发大（12306 在高峰日平均 1 秒就要承受 170 多万次点击），业务复杂（火车票的种类是动态变化的）。

1、从对数据的操作来看，无非是分成读和写两类。所以，本质还是处理读写、写写两类冲突，额外的特点是火车票是动态变化的，所以库存查询应该不适合使用REDIS之类的缓存，这样，数据库和缓存的同步成本太大了。

2、避免数据读写冲突。对不同数据的操作不会引起冲突——不同的路线不会冲突，所以应把不同的路线车票数据分开存储，这样降低了数据的并发，也减少冲突。相当于做了分库，需要在存储节点前加上带路由功能反向代理。

3、处理数据读写冲突。由于数据并发过大，为了提高处理速度，单节点不应该采用可串行化隔离级别。查询车票余量要尽可能实时，所以不需要可重复读；所以采用读已提交就可以了。同时，由于并发量比较大，也不应该采用乐观协议。

4、不需要分布式事务。一是分布式事务比较慢，影响处理速度；而是将不同路线分布到不同节点，单节点就应该足以应付数据量。

为了提高可靠性，需要考虑多机有容灾的情况，数据存储在多个副本上。为了保证交易结果的准确定，单调读\写，自读自写一致性，先读后写一致性都要满足，所以就是需要满足线性一致性。如果用关系数据库，那所有读写请求都需要发给主节点，高并发下的主从同步还是状态复制机，我的理解，比如MySQL之间同步用的BINLOG就是命令。节点状态的共识依靠分布式共识算法。

展开





