业务优化主要从业务逻辑上去规避对于高性能和高可用的太高要求，在满足业务场景的前提下，尽量减少性能要求。

场景一：

跑步记录上传，这个逻辑并不是一定要实时进行的，可以采取app端本地缓存结合异步上传机制，另外，对于用户的多终端场景，可以通过自定义协议实现增量记录上传。

这块逻辑会加重app端的业务处理逻辑，但是通过app端本地缓存和异步机制可以很大程度上减少服务端并发写压力，特别是在高峰期阶段，有效减少服务端压力。

• 跑步记录同步逻辑

  这里同步时相对于单个终端的记录同步，是多终端记录同步的一种特殊情况。

  

• 多终端同步逻辑

  这里同步场景是，用户通过多个手机安装了app，用同一个账户登录后进行跑步活动（当然一次只能登录一个app端），这样导致在某个终端上同步数据时需要保证和其他终端已经上传的数据的一致性，另外，在上传时服务端需要保证各个终端的本地操作最终在服务端保持一致，即如果某个终端删除了一条本地记录，那么最终服务端也应该是删除的。

  目前功能上只支持本地的新增和删除操作，本地不允许更新，所以复杂度要稍微小一些。

  我们通过数据版本号机制来保证服务端数据版本唯一性，每个终端的数据版本号向服务端版本号看齐，统一规则，即终端在同步数据之前必须先获取当前服务端的最新版本号，然后在进行对应逻辑的处理。

  

场景二：

跑步动态的生成，前提是跑步记录上传并落地后，而动态是给关注好友看的，个人主页上也能看到活动的动态，但是这些都不是有实时性要求，所以可以通过异步方式在服务端进行，消息队列很好的解耦记录上传后的动态生成。轨迹服务只要保证跑步记录上传成功并且写入消息队列成功即可，具体其他服务是否读取到该上传消息是不保证的，因为这个是由消息队列机制来保证的。这样可以有效减少动态的并发写压力，同时，对于动态生成后及时写入缓存，方便其他模块进行调用。我们通过一张图来看看如何实现。

以上的2个场景是Runnf的业务层优化的主要2个场景，其他比如福利模块，社交关系等不是主要的业务场景，不会产生写和读太大的压力，比如社交关系不可能达到微博这种程度，当然不保证随着业务发展，其他新增的业务也会产生较大的系统压力。那么最后我们应该明白，业务层优化应该是我们在系统设计时最先要考虑的，因为往往业务上的一点变通会给系统设计减轻很多压力，这是一个反复迭代的过程。