我们先在一个区里面把用户的票数加上去，另外设置一个定时器在后台，到一定时间，再把增量数据同步到另外一个分区的机房。虽然可能用户看到的数据会不一致，但是只要这个时间间隔过了之后，他们最终看到的还是一样的结果，这就是所谓的追踪一致。
这样一个简单的流程体验的调整，既提高了系统并发的性能，也满足了系统快速响应用户请求的体验需求，降低了系统对专线的依赖，提高了系统的容错性，可以说是两全其美。
其实还可以在前端做一些优化，用户只要一点击，就先让用户看到票数的增加，给到他们及时的反馈，而真正的数据甚至可能都没有到数据库这一层。
2. 如何去做有损服务?前文介绍了我们为什么要做有损服务，下文介绍我们如何做到有损服务？
有损服务的价值观里面有三大核心思想。
第一，放弃绝对一致，追求高可用和快速响应。在我们提供的服务里面，甚至在高并发的情况下，也要保证高可用，还有快速给用户应答。
第二，万有一失，一旦出现问题，能够让用户发起重试。
第三，伸缩调度，降级服务。伸缩调度可以说是有损服务里面的最高境界了。
简单来说，我们要在技术、产品上对业务做好这种结构的考虑，细分好业务模块，根据重要性的程度去做划分。回到口罩预约的例子中来，我们其实是放弃了实时一致，做到了快速响应。在他提交以后，告知用户已经在排队，过段时间也能看到结果，最终结果保持一致。如果用户一进来就全部给他们实时的接口，可能一开始就会导致雪崩。
另外一个从成本跟快速反应之间做权衡例子就是 QQ相册，QQ相册业务在07年到08年，处于一个快速的发展过程，一年时间内出口带宽增长了4倍，特别是在每天的7:30—9:30两个小时内，进入峰值，就如下图所示。
团队一开始是想继续保持这种刚性的系统，通过扩容增加预算，为用户提供百分百的无损体验，但是会花费巨大的带宽和存储成本。如果只是为了满足这两个小时的尖峰体验，团队可能会疲于奔命难以维持，因为它的业务发展非常快，量级也一直在增加。
在有损体验思想的指导下，团队实行了新的策略，放弃绝对一致，追求速度一致。
如下图所示：右边伪代码显示的就是这样一个策略，节省了20%的带宽，但用户在高峰期也可以快速得到页面的反馈，付出的代价仅仅是在这两个小时内，用户可能损失了快速查看下一张高品质大图的这样一点点的体验，但是换来的却是在有限的资源情况下，能提供高峰下这种一秒反应的体验。
右边部分是发送消息的场景，像IM这样的即时通讯系统，及早响应发送成功，异步尽力投递，绝大部分消息及时送达对方，极少量消息延迟或者丢弃，让用户自己重试，简单、快速，而又高效 。
就像微信那样，如果你发一个消息，在还没成功的时候，它会一直转圈圈，如果发送失败会有个小感叹号，再点击一次就能重新发布了。
在产品设计上我们也要给用户一个正向的、可感知的反馈，然后用户就会根据相关的提示来做响应的动作。其实没必要完全由系统去做这个事情，只要一失败就不断重试，用户他自己就会做，完全可以通过产品的设计来进行弥补。
再看看口罩预约，其实我们是分批放行，还有失败重试策略也是参考这个思路。
下面再来看一下伸缩调度降级服务，伸缩调度降级服务是有损服务里面的最高境界，要求我们在技术上把系统单元化、模块化，每个逻辑单元做到高内聚、低耦合。
不单单是技术上，产品上我们也要做一样的考虑，去细分业务的模块，根据重要程度去分级，承载不同的资源场景。比如服务器端的计算资源、带宽存储专线等等，实现分级控制。