项目实际开发过程中，往往有很多场景需要设计实现。而且如果设计不得当，后期会出现很多问题，甚至有可能会导致项目延期或者失败。今天给大家介绍我们项目的几个应用场景，当然不一定是最完美的方案，童鞋们一定要根据实际情况酌情处理。

想学习分布式、微服务、JVM、多线程、架构、java、python的童鞋，千万不要扫码，否则后果自负~

应用场景：

1.用户分润结算场景：

业务背景： 用户可以将自己的积分存入积分宝（类余额宝），平台每天凌晨需要给用户结算，前一天的分润金额。

技术实现： 通过elastic-job分布式调度框架来实现分布式定时任务，因为涉及到整个平台的用户积分的分润，用户量大的情况下面，可能会有海量的数据，如果只在一台机器上面执行的话，耗时又耗力，通过将任务均匀的分配到不同的服务器上面，可以有效的解决类似的问题，后期也可以通过增加服务器来横向扩容。

2.商品首页过期数据处理：

业务背景： app商品首页的数据是通过后台配置的，但是这些配置的商品有可能会被下架或者删除，所以需要及时清理掉这些失效的数据。

技术实现： 因为需要循环遍历首页配置的商品列表，如果是实时同步的话，会影响性能，所以这边采用定时任务的方式，定期清理过期的数据。这边需要注意的是：因为数据量比较少，只需要单个服务跑定时任务就可以了，但是生产中一个服务会部署多个实例，所以需要限制只在一个服务实例跑就可以了，否则就会重复跑相同的任务了。

3.es商品数据更新：

业务背景： app商品搜索有综合排序功能，需要将用户的销售量、评论数、更新时间、好评率等综合一起进行排序。

技术实现：

方案一： 在es商品表中增加一个用于综合排序的字段，如果只是修改商品个别商品的销售量、评论数、更新时间、好评率等，只需要发一个MQ消息，异步的去刷新es的商品数据（还有一种比较野蛮的方式，不管商品修改多少个，定期跑定时任务全量更新所有商品数据，但这样太损耗性能了）。但是如果是排序的规则发生变化，则需要同步所有的es商品数据（所以尽量不要频繁修改排序规则）。

方案二： es商品表中不增加额外的综合排序字段，如果只是修改商品个别商品的销售量、评论数、更新时间、好评率等，只需要发一个MQ消息，异步的去刷新es的商品数据（也可以将需要更新的商品数据先记录下来，然后在用户流量少的时刻，统一进行更新操作），如果是修改商品排序规则，则直接修改排序的公式，不需要修改任何的es数据。这种方案相对优于第一种方案。

4.商品数据库数据和redis数据不一致

业务背景： app商品详情页面从redis获取，运营后台数据从数据库中获取，二者数据不一致。

技术实现： redis数据最害怕就是和数据库不一致，因为你不知到底是哪一条数据不一致。进行全量更新明显不太现实，所以很多时候都是发现错误的时候，进行数据矫正。当然我们需要知道数据不一致的根源，如果数据库操作在一个事务里面，事务出错回滚，redis没有做相应的回滚处理，那肯定就会出现数据不一致。所以一定要保证数据库更新操作和redis一致，出错一起回滚，但是这种方式会增加系统的复杂度，有可能还是会出现问题，最好的方式是在修改数据的时候，直接清空redis数据，然后查询的时候，如果数据不存在，就将数据同步到redis上面，这样就会大大的提高安全性，又不会增加系统复杂度。

5.二维码收款需要实时显示付款信息

业务背景： 二维码收款时候，收款方要实时显示付款的结果给卖家。

技术实现：

方案一： app端不断的进行接口请求，直到付款结果出来或者用户退出二维码收款码页面。这种方式缺点很明显，损耗性能，如果同一时刻收款人数非常多，就会造成高并发，优点是技术实现成本低。

方案二： 通过长连接来实时显示付款结果，比如用Netty、websocket、tcp之类的，这样就可以避免第一种缺陷，不管同一时刻商家有多少个，都不会有并发的风险，但是技术实现难度会比第一种要大。

6.多个账户财务数据对应不上

业务背景： 用户有积分分润的账户、商品分销收益的账户、用户余额的账户。其中分润账户和分销账户可以转账给余额账户，余额账户是可以真正提现的账户。每个账户都有自己的记录表，但是各自的账户金额有些数据对应不上。

技术实现： 在设计的时候尽量将这些账户体系放在同一个服务中，这样就不会有分布式事务的问题了。如果实在不行，必须分为多个服务，那就要保证数据先入一个服务，在插入到其它服务中，简而言之就是要先保证有一个账户里面的数据是对的，而且有交易流水日志之类的。最重要的是要定期进行程序对账，千万不要等测试或者用户反馈这些问题，要防患于未然。

7.多人审核重复点击产生多条数据

业务背景： 运营后台进行数据审核的时候，会发生多人同时审核同一条记录的情况，造成产生两条数据的结果。

技术实现： 基于这种情况一般要做两手准备，一个是在操作的时候需要加并发锁（可以用redis锁来控制），这样可以保证在同一时间只有一个人在操作，但是一定要注意锁的颗粒，千万不要太大。第二步，在插入数据之前，要先查询一遍，不要直接插入，保证数据库没有相同的数据。

8.用户积分更新数据有误

业务背景： 用户购买商品成功之后，积分更新数据和这个商品设置的积分数据对应不上。

技术实现： 原因可能会有多个，一种可能是当时商品那一刻发生变化，所以导致积分和最新的商品积分对应不上。还有一种情况可能是因为积分是直接前端传过来的，并不是后台直接查询的，所以插入如果能从后台取，一定要从后台取，不要过分信赖前端带过来的数据。

林老师带你学编程：https://wolzq.com