技术人

购物车与商品用户的交互问题：​1.首先，分析问题的背景：​当用户在商品的界面点击立即购买的时候，如果没有购物车，那么现有的架构是：​直接调用api传输商品详情+卖家Id+买家ID，直接跳转到支付界面上，例如填写个人信息，填写地址......​上述的方式对于购买流程而言，需要设计的只有：服务之间的同步，那么就引发了一个问题：当我用户点击立即购买的时候，需要直接将商品的状态进行锁定吗？如果锁定的话，那么锁定的时间是多少？如果不锁定的话，商品被别人买走了怎么办？假如锁定的话，会不会出现恶意购买？如果不锁定的话，库存问题如何解决？这是我目前项目中出现的问题，以前的架构是：​假如我点击立即购买的时候，则锁定了商品，此时这个订单处于待支付状态，这也出现了我朋友的实际在应用层面的黑盒测试的时候，出现了这个问题，其他朋友就无法正确的访问这个商品了，此时虽然支付时间回调是5分钟，但是这个过程等待十分久，假如很多人同时只点击购买不支付，或者别人只想看看呢？这就是一个bug了​针对这个bug，我的想法是这样的：​前端: 携带 商品ID、数量、用户ID 请求订单服务。订单服务 收到请求后，不会立即操作数据库。它会先去查询 商品服务 获取商品信息（价格、名称等），并检查缓存中的可预扣减库存是否充足。如果 Redis 中的 `product:stock:123` 的值大于购买数量，订单服务就在 Redis 中将库存减掉，并生成一个有时效性的临时订单，有效期是 10分钟，返回临时订单号，前端跳转到支付确认页面。这个页面上会有一个倒计时，提醒用户在规定时间内完成支付。​另外，我在想，二手闲置商城，需要购物车模块吗？​欢迎大家评论讨论

在 1.对于发布商品和交易的总数的时候，数据库的设计：因为对于发布者发布的总商品和交易的总数，这部分不仅仅只是涉及到用户表，同时也涉及到商品表，那么在我的二手闲置商城中，为了确保系统的性能以及可扩展性，不应该盲目尊崇数据库设计的范式，而是实现数据库表的yonyu字段，使其反范式化那么分析一下，第一版我对于商品与用户的表设计时，考虑的是在商品与交易表中实时的通过count去计算我们的商品数，这样在用户界面时查看自己的交易与发布的商品的时候，能够实时的去计算和查看我们的发布的商品总数和交易总数，但是这样也带来了一系列问题，如，当我们用户不断的去发布商品和交易的时候，对于我们的数据库带来的性能压力是极大的，可以想象，当用户的商品积累至万级时，所损耗的性能了，每次访问都需要计算对于初期是可以的，但是并不优雅​那么我的第二版解决方案是什么呢？ 即在用户表中实现插入yonyu字段，将用户发布的商品使用计数器的形式去写入数据表中，这样，我们就可以通过查询用户的字段即可实现读取交易总数和发布商品的总数，但是会出现什么问题呢？每当用户发布一个商品或完成一笔交易，都需要更新 `users` 表中的这个计数字段。这会导致对用户表的高频写入，在高并发下容易产生行锁竞争，影响核心用户服务的性能。​但是对于我的这个小平台而言，这已经是比较好的一个设计方式了，对于业务增长没有怎么大的情况下，这可以应对1000-2000人的使用。但是，作为一个优雅的程序员，我已经在这部分埋点了，这部分后期我需要去实现第三版优化。具体的优化方式为：​在深入了解了EDA，RabbitMQ的底层原理，我可以确定的是，我们完全可以去是实现一种读写分离，并且考虑最终一致性的一个设计模式，对于微服务而言，我们并不需要去对商品，用户，订单服务进行额外的增加yonyu字段，而是可以去考虑在用户行为模块中，实现DDD架构中的聚合模式，想象一下，目前我的商品模块在发布商品的时候，已经实现了RabbitMQ的异步发布机制，当然，这部分的商品发布机制对应的只是个性化推荐系统的商品推荐，那么我能不能在用户行为模块中实现一种消费机制，实现用户的发布商品与交易商品的回显呢？当然可以，用户的行为模块是关于收藏，点赞发布评论，这些都是可以实现异步机制的，我们不需要实时的去显示，而是为了考虑最终一致性而设计的。

最近刷到一篇帖子，叫“你的五行藏着你赚钱的行业”，自我感觉也没上年纪呀，怎么都给我推这些文了，主要是讲一个人适合干什么，往往不是学历决定的，也不是兴趣决定的。。。其实是一个月前的事情了。对于这些，一直是半信半疑的状态，信则有，不信则无吧。碰巧的是，我朋友这段时间一直在研究“mbti对择业的影响”，他说要拿我做试验，我们就玩了一下，下面是他给我的结果（严重怀疑他是对着答案问问题）：“你优势在于既懂技术，也对业务有敏锐度，这使你能快速判断什么值得做、怎样做出结果。你可能更适合直接看到产出的岗位，离业务近一些，能及时获得反馈、看见自己创造价值的地方，会让你更有成就感。”虽然我并不清楚背后的推演逻辑，...