分布式金融架构课
任杰
eBay 支付账务系统负责人,前蚂蚁金服架构师
19876 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
开篇词 (1讲)
分布式金融架构课
15
15
1.0x
00:00/00:00
登录|注册

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

你好,我是任杰。
今天是大年初一,首先祝你春节快乐,身体健康。专栏的正文部分已经结束,相信这几个月的时间,你已经学到了很多。为了让你过节期间能够轻松一些,同时也能巩固之前所学,这个春节假期,我一共为你安排了 3 期特别策划的内容。
今天是策划的第 1 期,我从之前学的课程里精选了一些知识点,给你出了这一套测试题,帮助你检验学习成果。客观题的答案和解析,你在测试后就能直接看到。主观题我暂时不公布答案,给你留下一定的思考时间。
第 2 期我会为你整理一份我的推荐书单。
第 3 期,我会公布主观题的参考答案。有必要的地方,我也会说明对应前面课程的哪一节课,方便你查漏补缺,根据需要去复习巩固相关内容。
好了,那今天我们就先牛刀小试,通过测试题来练练手吧!
首先我给你出了 10 道客观题,5 道多选,5 道单选,你可以点击文稿中的答题按钮进入测试。
完成客观题之后,这里还有两道主观题在等着你。金融系统的特点是要求高,所以当你学会了如何解决金融行业的问题之后,其他行业的问题也就是手到擒来的事了。所谓它山之石可以攻玉,我们来看一看下面这两道其他行业的经典问题。

春运卖票

除了支付以外,技术圈还有一个广为人知的高难度系统是卖火车票。你可以从 2020 年初的这个新闻片段感受以下技术挑战的难度:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

这篇文章是任杰在春节期间为读者准备的特别策划内容。他精选了之前学习的知识点,出了一套测试题,帮助读者检验学习成果。除了客观题的答案和解析,还有两道主观题需要读者思考。此外,任杰还提到了第2期的推荐书单和第3期将公布主观题的参考答案。文章还涉及了金融系统的特点和技术挑战,以及《王者荣耀》游戏的前端和后端设计思路。整体来说,这篇文章为读者提供了春节期间的学习和思考内容,既能够巩固之前所学,又能够在节假日轻松愉快地度过。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式金融架构课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(2)

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