Browsed by
日期:2020年5月4日

铁路订票系统的简单设计

铁路订票系统的简单设计

閱讀本文約花費: 6 (分鐘) 其实铁路订票系统面临的技术难点无非就是春运期间可能发生的海量并发业务请求。这个加上一个排队系统就可以轻易解决的。 本来我在 weibo 上闲扯两句,这么简单的方案,本以为大家一看就明白的。没想到还是许多人有疑问。好吧,写篇 blog 来解释一下。 简单说,我们设置几个网关服务器,用动态 DNS 的方式,把并发的订票请求分摊开。类比现实的话,就是把人分流到不同的购票大厅去。每个购票大厅都可以买到所有车次的票。OK ,这一步的负载均衡怎么做我就不详细说了。 每个网关其实最重要的作用就是让订票的用户排队。其实整个系统也只用做排队,关于实际订票怎么操作,就算每个网关后坐一排售票员,在屏幕上看到有人来买票,输入到内部订票系统中出票,然后再把票号敲回去,这个系统都能无压力的正常工作。否则,以前春运是怎么把票卖出去的? 我们来说说排队系统是怎么做的: 其实就类似我们去热门馆子吃饭拿号。只不过要防止别人伪造号插队而已。 如果你来一个人(一次 HTTP 请求),我就随机产生一个我做过一些签名处理的号码返回给你。暂时称为 ticket id 。这个 ticked id 是很难伪造的。 系统在内存里开一个大数组(32G 内存够排上亿人了吧),就是一循环队列。把这个 ticket id 放在队列尾。 用户现在拿着 ticket id 向网关发起请求。网关利用一次 hash …

Read More Read More

由12306.CN谈谈网站性能技术

由12306.CN谈谈网站性能技术

閱讀本文約花費: 31 (分鐘) 12306.cn网站挂了,被全国人民骂了。我这两天也在思考这个事,我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促,而且完全基于本人有限的经验和了解,所以,如果有什么问题还请大家一起讨论和指正。(这又是一篇长文,只讨论性能问题,不讨论那些UI,用户体验,或是是否把支付和购票下单环节分开的功能性的东西) 业务 任何技术都离不开业务需求,所以,要说明性能问题,首先还是想先说说业务问题。 其一,有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的,网游和QQ在线或是登录时访问的更多的是用户自己的数据,而订票系统访问的是中心的票量数据,这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。其二,有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似,但是如果你的思考不在表面的话,你会发现这也有些不一样。火车票这个事,一方面会伴随着大量的查询操作,更BT的是下单的时候需要对数据库很多的一致性的操作,一方面是从起点到终点各个分段票的一致性,另一方面,买的人路线、车次、时间选择有很多,会不停地改变下单方式。而秒杀,直接杀就好了,没有那么多查询和一致性的问题。另外,关于秒杀,完全可以做成只接受前N个用户的请求(完全不操作后端的任何数据, 仅仅只是对用户的下单操作log),这种业务,只需…

Read More Read More

B站《后浪》是如何击中人心的

B站《后浪》是如何击中人心的

閱讀本文約花費: 10 (分鐘) 五四青年节的前夕,忽如一夜春风来,朋友圈被B站的新广告刷屏了。何冰老师贡献了一个精彩的演讲《后浪》。(点击图片观看演讲视频) 我发现一个有趣的现象,在朋友圈里,不论70后、80后、90后、00后,都在转发这个视频,这是极少见的能打通多个人群的内容。在五四青年节,B站将会通过这个视频获得亿级的曝光量,并会大量获得超出原有用户年龄层的新用户。B站以六位数的投入,达成了一个千万级广告投放的效果,投资回报率惊人。这是一次出色的营销,也是一个精彩的商业演讲。一个演讲,B站是怎么做到让如此多不同人群来转发的呢?用一句话概括,就是把【共情】用到极致。作为沟通与表达的专业教练,我一直在研究:什么样的内容,不论是文字、还是视频,能够使人在看完之后产生强烈的冲动,想把它转发给更多人?我总结下来有这么几种类型:第一类,是一个全新的认知、知识、或信息,它对我们非常有用,对其他人也很有用,我们会很愿意分享。这是能够带来现实价值的一种新知。 第二类,能够带来娱乐价值的,博人一笑的。第三类,是看完之后能引发我们强烈的情绪。传播内容的情绪符合我们内心深处潜意识里的那种情绪,通常与个人的三观有关,因此会引发大量的传播。前不久当我们看到武汉的一位医生去世时,我看到很多人在各类社交媒体上进行转发纪念。同样的,一些容易引发人们群情激奋的事件,也容易获得迅速传播,比如渣男出轨,虐…

Read More Read More

第七章 Rocketmq–消息驱动

第七章 Rocketmq–消息驱动

閱讀本文約花費: 16 (分鐘) 接上文,本文主要介绍了MQ是什么,及它的应用场景,消息发送和接收演示以及相关的案例。 7.1 MQ简介 7.1.1 什么是MQ MQ(Message Queue) 是一种跨进程的通信机制,用于传递消息。通俗点说,就是一个先进先出的数据结构。 7.1.2 MQ的应用场景 7.1.2.1 异步解耦 最常见的一个场景是用户注册后,需要发送注册邮件和短信通知,以告知用户注册成功。传统的做法如下: 此架构下注册、邮件、短信三个任务全部完成后,才返回注册结果到客户端,用户才能使用账号登录。但是对于用户来说,注册功能实际只需要注册系统存储用户的账户信息后,该用户便可以登录,而后续的注册短信和邮件不是即时需要关注的步骤。 所以实际当数据写入注册系统后,注册系统就可以把其他的操作放入对应的消息队列 MQ 中然后马上返回用户结果,由消息队列 MQ 异步地进行这些操作。架构图如下: 异步解耦是消息队列 MQ 的主要特点,主要目的是减少请求响应时间和解耦。主要的使用场景就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列。同时,由于使用了消息队列MQ,只要保证消息格式不变,消息的发送方和接收方并不需要彼此联系,也不需要受对方的影响,即解耦合。 7.1.2.2 流量削峰 流量削峰也是消息队列 MQ 的常用场景,一般在秒杀或团队抢购(高并发)活动中使用广泛。…

Read More Read More

第六章 Sleuth–链路追踪

第六章 Sleuth–链路追踪

閱讀本文約花費: 11 (分鐘) 本文介绍微服务架构中最重要的设计模式:微服务之间的数据通讯。更多请看全文。 6.1 链路追踪介绍 在大型系统的微服务化构建中,一个系统被拆分成了许多模块。这些模块负责不同的功能,组合成系统,最终可以提供丰富的功能。在这种架构中,一次请求往往需要涉及到多个服务。 互联网应用构建在不同的软件模块集上,这些软件模块,有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心,也就意味着这种架构形式也会存在一些问题 于是就出现了下面几个 问题 如何快速发现问题? 如何判断故障影响范围? 如何梳理服务依赖以及依赖的合理性? 如何分析链路性能问题以及实时容量规划? 分布式链路追踪(Distributed Tracing),就是将一次分布式请求还原成调用链路,进行日志记录,性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪 台机器上、每个服务节点的请求状态等等。 常见的链路追踪技术有下面这些: cat 由大众点评开源,基于Java开发的实时应用监控平台,包括实时应用监控,业务监控 。 集成方案是通过代码埋点的方式来实现监控,比如: 拦截器,过滤器等。 对代码的侵入性很大,集成成本较高。风险较大。 zipkin 由Twitter公司开源,开放源代码分布式的跟踪系统,用于收集服务的定时…

Read More Read More