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

想学习分布式、微服务、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

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐