春节策划第1期 分布式金融系统知识，你掌握了多少？
你好，我是任杰。
今天是大年初一，首先祝你春节快乐，身体健康。专栏的正文部分已经结束，相信这几个月的时间，你已经学到了很多。为了让你过节期间能够轻松一些，同时也能巩固之前所学，这个春节假期，我一共为你安排了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期春节策划里公布，敬请期待！
- 小动物 👍（4） 💬（0）
春运卖票 首先，先聊操作类的行为，主要就是购票。 对于购票人而言，关心的是购票结果，对花费的时间有一定的容忍度。 当用户发起下单，那说明一定选择了某辆车。那么就是购票人对某两车的票进行操作。在保证正确性的情况下，第一反应就是队列，所有对同一辆车的购票行为丢进同一个队列中，顺序处理。同一班车虽然因为不同岂止站导致车票组合情况很多，但实际票的数量固定，且数量级并不大。若真的因为购票人数多，排队过长，也问题不大，因为票很容易就卖完。后续的人不需要处理了。 从这个方案出发，服务器可以按车次来配置路由，保证热门线路。 对于查询。在没有查询换乘方案时，查询结果的数量并不多。且查询时应该可以接受一定的错误，毕竟查询和实际下单有时间差，票数量差个几张问题不大。那可以做一定的缓存保证查询。 王者荣耀 玩家每一个操作可以看成一个命令。后端可以按事件溯源架构来设计。在断线恢复后，将断线期间的事件同步至本地，恢复玩家状态即可。
2021-02-12 - tt 👍（3） 💬（0）
老师过年好，祝您新春快乐！ 对于第一个主观题，我是这么思考的。 首先，火车票动态SKU是12306的核心域，应该花很大的成本去改进，就像课程所说，12306也有雄厚的财力可以去解决，但是有啥特殊的硬件，我还不知道。这里就从咱们课程主要涉及的数据处理的视角出发去思考。 其次，购买火车票的过程主要涉及的是交易数据，应该使用关系性数据库处理最核心的交易环节。 最后，火车票售票张数绝对量很大（全国铁路已累计发售车票 1.75 亿张，每天的发售量都在 1000 万张以上），交易并发大（12306 在高峰日平均 1 秒就要承受 170 多万次点击），业务复杂（火车票的种类是动态变化的）。 1、从对数据的操作来看，无非是分成读和写两类。所以，本质还是处理读写、写写两类冲突，额外的特点是火车票是动态变化的，所以库存查询应该不适合使用REDIS之类的缓存，这样，数据库和缓存的同步成本太大了。 2、避免数据读写冲突。对不同数据的操作不会引起冲突——不同的路线不会冲突，所以应把不同的路线车票数据分开存储，这样降低了数据的并发，也减少冲突。相当于做了分库，需要在存储节点前加上带路由功能反向代理。 3、处理数据读写冲突。由于数据并发过大，为了提高处理速度，单节点不应该采用可串行化隔离级别。查询车票余量要尽可能实时，所以不需要可重复读；所以采用读已提交就可以了。同时，由于并发量比较大，也不应该采用乐观协议。 4、不需要分布式事务。一是分布式事务比较慢，影响处理速度；而是将不同路线分布到不同节点，单节点就应该足以应付数据量。 为了提高可靠性，需要考虑多机有容灾的情况，数据存储在多个副本上。为了保证交易结果的准确定，单调读\写，自读自写一致性，先读后写一致性都要满足，所以就是需要满足线性一致性。如果用关系数据库，那所有读写请求都需要发给主节点，高并发下的主从同步还是状态复制机，我的理解，比如MySQL之间同步用的BINLOG就是命令。节点状态的共识依靠分布式共识算法。
2021-02-16