11 | 系统优化:如何让金融系统运行得更快?
任杰
你好,我是任杰。
这节课是我们第二个模块“系统正确性保障”的最后一节课。在第二个模块里,我们一起学习了如何正确地处理数据和计算,以及如何做好数据的传输和存储。
不过系统设计得再好,如果不能及时地完成业务处理也不行。所以,在最后一节课里我给你讲讲如何让金融系统运行得更快。
我们重点来看为什么不同业务有不同优化需求,以及常见的优化方式和问题有哪些。吃透了这些优化思路,不但能让你对金融系统的优化有一个系统性的认识,也方便你后续根据自己的需要有针对性地学习提高。
背景分析
“快”在不同的环境下有不同的定义。对于互联网业务来说,快一般意味着吞吐量大。对于金融业务来说,快意味着延时低。
那为什么会有这两种定义的区别呢?我们先来分析一下互联网业务。互联网业务在经济学上有一个特点是边际成本(Marginal Cost)基本为零。
边际成本决定了业务扩张的成本,所以既然扩张成本很低,那么互联网业务倾向于扩张,而且是大规模扩张。扩张的结果就是互联网业务会有大量的用户,这也决定了互联网业务需要解决的是大流量问题。
那流量大为什么和速度快扯上关系了呢?我说个实际例子你就清楚了。
不知道你有没有在网上秒杀过商品。秒杀的时候你会发现网页变得非常卡,半天显示不了内容。这时候你肯定会抱怨网站速度慢,这是因为在解决秒杀这种大流量问题的时候,互联网通常采用解决方案是用延时来换吞吐量,也就是通过降低你的网页加载速度来支持更多的人秒杀。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了金融系统优化的重要性,着重从系统正确性保障的角度出发,探讨了如何提高金融系统的运行速度。文章首先解释了互联网业务和金融业务对“快”的不同定义,以及背后的经济学原理。随后,重点介绍了吞吐量优化的两种常见方法:分库分表和使用消息队列。分库分表通过横向和纵向切割数据库表,充分利用多台机器的硬件资源来解决大流量问题,但也带来了一系列问题。另一种优化方式是通过消息队列,将流量先写入到消息队列中,然后服务器按照固定的速度处理消息队列内的消息,从而避免服务器过载。此外,文章还介绍了延时优化的方法,包括单机优化和网络优化。通过深入浅出的方式,为读者提供了系统优化的技术特点和挑战,为金融系统的优化提供了有益的参考。 文章还介绍了Linux上比较有用的几个函数,如`epoll`和`io_uring`,它们可以解决网络消息处理的问题。`epoll`可以同时监听大量的网络链接,而`io_uring`则解决了用户态切换过多的问题,通过批量处理网络操作,节省了状态切换和数据拷贝开销。这些技术对金融系统的优化具有重要意义。 总的来说,本文通过对金融系统优化的技术特点和挑战进行了深入探讨,为读者提供了系统优化的有益参考。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式金融架构课》,新⼈⾸单¥59
《分布式金融架构课》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(6)
- 最新
- 精选
- 楼下小黑哥入账热点账户问题,是支付系统不可避免会碰到的问题。 目前个人见过的解决方案放为两种,。 第一种缓冲记账,相关账务记录缓冲区成功救结束,然后定时将缓冲区账务汇总,更新到账户余额里。 这种做法,通过减少更新次数,提高性能,主要缺陷是余额不能实时更新。 第二种、拆分账户表,将一个账户,拆分为一个主账户,与多个子账户。 平常只使用主账户,热点的时候余额都记录在子账户。 这种方式通过水平扩展的方式,提高性能。 上述两种方法比较适合与入账环节,但是如果还涉出帐,上述方式还是存在缺陷,这个不知道老师有没有更好解决方案?
作者回复: 这位同学你好。你提到的基本上是常用的几个方案。还有一个方案是用更好的硬件,比如IBM的Z系列大型机。这也是过去一些金融机构常用的解决问题的方案。
2021-01-2529 - tt当时从部队转业的时候选择了金融行业,觉得从事这个行业的好处就是可以接触各个其它行当,能了解到更多。 随着工作年限的加长,确实感受到了不同行业由于各自特点不同而造成的冲击。一个团队内的同事由于负责不同的业务,思维方式都有所不同。这种某种意义上的“跨界”或者“交叉”促使自己不断思考。 老师今天从本质上把互联网和金融的区别和联系点透了;把高吞吐和低延迟这两个经常出现在一起的名词推向了两个方向,并最终落到了“普惠金融”和“机构金融”上。这种运用基本概念去分析问题、观察问题的方式太值得学习了。 很多时候不识庐山真面目,只缘身在此山中。在各自的领域习以为常的东西常常会变成一种不自觉。 对于今天的问题,所谓大机构的账户就是面对很多个人或其余第三方的账户,也就是一对多或者说“一对特别多”的账户。 这样的账户往往是入账或贷记操作比较多,即要让它可以很快的增加余额而不出错。这样可以把它分成多个子账号,每个账号分别做入账,让后日终的时候再汇总。 或者把金额记录到一个科目里,由于是入账,可以没有余额的概念,这样也不会出错,这样连累加的过程也可以省掉了。而且记录的过程都是新增,可以顺序写,也可以提高性能。2021-01-1510
- 鱼感觉限于篇幅老师没有深入聊。补充一些我了解的。对于我们应用开发CPU绑定最常见的就是Nginx CPU绑定,实现原理就是老师提到的C函数sched_setaffinity。 内存的顺序访问更快的原因是,CPU从内存读取数据到缓存中和标记缓存失效都是以CacheLine为单位,再加上利用分支预测的硬件预读取导致。金融业务访问多维数组时,其实可以使用软件预读取改善这个问题。 网络优化不一定上来就使用epoll,在连接数少(拷贝数量小)并且十分活跃(事件密集)的情况下,poll和select效果可能更好。看全款选择吧,另外老师提到的io_uring目前似乎还不太成熟,生产环境慎用吧。2021-06-097
- lukenuma架构,线程绑定,cpu缓存,内核旁路,低延迟网卡,。。。2021-01-156
- webmin区分账户是入账多还是出账多。 1. 如果是入多的话,先用追加的方式记录流水,一段时间合计一次金额加到账户上; 2. 如果是出账多的话,一方面追加记录流水,另一方面把一定比例的余额加载到缓存系统(如redis),通过缓存系统的原子操作来扣减,一段时间合计明细来扣减DB账户上的金额并修正缓存中的余额。 另可以结合授信思路对于扣减多的大客户账户可以有一定额度的超付。2021-01-215
- Palmer老师你好!这节课提到的几个吞吐量优化的技巧很有用,想再请问下,DVP场景下是否有吞吐优化设计推荐呢?2021-05-05
收起评论