第4层缓冲就是当用户提交之后我们其实并没有马上进行处理，而是会将请求先丢到一个队列里面，有一个后台程序会按照先进先出的机制做处理，最后返回用户最终结果。
整个策略调整下来，相比原来的无损方案来看，其实我们算是提供了一个有损的服务。
为了解决这种短时间高并发的问题，我们后端是通过三个方面的设计来应对的。
第一，借助消息队列的技术，利用Kafka进行削峰的排队处理，保证服务的响应速度。
第二，在业务数据入库的时候，采用的是顺序插入的方式去捕捉、修改和删除，最大化保证数据库文件的写入速度。
第三，我们采用了Redis来做缓存，减少数据库的并发查询操作，保证高并发状态下的查询速度。
具体来说，在我们的设计里面分了两层，一个是Preorder Servives，另一个是 Spoorder Services。Preorder Servives主要是给前端去做提交预约、登记以及预约查询等服务提供接口。可以避免在超高并发的情况下去查询数据库，而且我们也通过这种分配的技术，将数据分散到不同的分片，后续更容易实现水平的扩容。
Spoorder Services 是用来处理用户预约请求的一个服务，它通过订阅消息队列的方式去处理这些数据，将预约的结果写入数据库，另外它也会把相关的一些结果信息写到缓存里面。分层之后，对外服务的过程其实就相当于一个异步的过程了。
前端部分，通过各个关键节点的开关控制，动态调节服务器压力。
第一，在首页读取 CDN 配置，为应对相对较小的集群出现负载过高情况，我们将缓存时间改为10分钟。
第二，在预约说明页我们会去引导用户做自查上报，通过这种方式去分流这部分没有登记做过自查上报的用户，从而减低了口罩服务器的压力，起到削峰的作用。
第三，使用微信的 Autofill 能力。Autofill 是可以跨小程序保存用户上次填写过的一些信息，包括姓名、身份证、地址、护照等等，这样用户就可以很方便选择他上一次提交过的信息，而不需要每次再重新填写,提升了用户体验。
第四，实行分批放行，不管是放行的比例，还是用户预约失败后重置的秒数都是可以配置的。当后续发现流量瓶颈远远没达到阀值的时候，我们可以选择放开配置。
同时对于经常变动的文案、开关、配置、时间变量等等，基本都是放到了配置文件里面，这样就使得我们可以非常便捷地去做一些动态运营。
口罩预约功能上线以后，首日访问量达1.7亿，抗住了10W+的QPS。
上线过程并不是一帆风顺的，口罩预约上线不久后，开始陆续收到同事或者朋友反馈说他们都成功预约上了。我们当时还觉得很纳闷，因为预约结果是异步处理的，我们有一个开关，等处理完后把开关打开，用户才能看得到结果。为什么我们还没有把预约结果的开关打开，他们就看得到结果呢？
一看截图才发现，原来是文案出现了问题。之前的提示文案“预约已经登记完成”很容易会误导用户，让他们以为已经预约成功。其实这里其实还有下半句：预约已登记完成，结果会稍后公布。但是因为文案太长，我们把它写到下面的小字上了。所以很多用户就误会了。
当政府知道这个消息之后，非常担心会导致线下的人群聚集。所以我们紧急开了个会，决定要通过短信的方式通知用户，让他们第2天不要去线下门店取口罩。于是我们就跟政府一起去紧急协调这种可以发短信通知的部门或渠道，最终找到了相关的部门帮我们把所有短信给发出去了。
第2天紧急调整了一些文档，明确告诉用户，现在只是排队中，同时我们后面的版本陆续增加了订阅通知，不再依赖短信，改用微信的订阅通知。同时也增加了线上支付快递到家等功能。
五、架构师如何做好有损服务下文会着重展开介绍，什么是有损服务，我们又该如何去做好有损服务呢
有损服务其实是腾讯海量之道的两大技术价值观之一。
