经典项目应用场景分享-上，tomcat常见面试题

最新推荐文章于 2024-11-03 22:34:49 发布

m0_60607895

最新推荐文章于 2024-11-03 22:34:49 发布

阅读量407

点赞数 5

分类专栏： 2024年程序员文章标签： oracle 数据库

本文链接：https://blog.csdn.net/m0_60607895/article/details/136887035

版权

2024年程序员专栏收录该内容

7 篇文章 0 订阅

订阅专栏

文章讨论了在电商、支付和财务系统中遇到的技术挑战，如如何高效地同步ES商品数据、处理数据库与Redis数据不一致、实现实时付款信息展示以及解决多账户数据对应问题。作者提出了两种方案，并强调了并发控制和数据一致性的重要性，以及提供了一些建议和资源链接。

摘要由CSDN通过智能技术生成

方案一：在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锁来控制），这样可以保证在同一时间只有一个人在操作，但是一定要注意锁的颗粒，千万不要太大。第二步，在插入数据之前，要先查询一遍，不要直接插入，保证数据库没有相同的数据。

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Java工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。