在研发项目中，经常能遇到复杂的状态流转类的业务场景，比如游戏编程中NPC的跳跃、前进、转向等状态变化，电商领域订单的状态变化等。这类情况其实可以有一种优雅的实现方法：状态机。本文重点介绍有限状态机，并结合具体项目，通过状态机的应用将状态和业务逻辑解耦，便于简化复杂业务逻辑，降低理解成本。另外，重点讲解如何优雅的解决更广泛的复杂业务问题。
RocketMQ事务的使用场景 单体架构下的事务 在单体系统的开发过程中，假如某个场景下需要对数据库的多张表进行操作，为了保证数据的一致性，一般会使用事务，将所有的操作全部提交或者在出错的时候全部回滚。以创建订单为例，假设下单后需要做两个操作： 在订单表生成订单 在积分表增加本次订单增加的积分记录
小编工作中负责业务的一个服务端系统，使用了 Elasticsearch 服务做数据存储，业务运营人员反馈，用户在使用该产品时发现，用户后台统计的订单笔数和导出的订单笔数不一致！对此进行排查并进行总结
一个接口可能需要调用 N 个其他服务的接口，这在项目开发中还是挺常见的。举个例子：用户请求获取订单信息，可能需要调用用户信息、商品详情、物流信息、商品推荐等接口，最后再汇总数据统一返回。 如果是串行（按顺序依次执行每个任务）执行的话，接口的响应速度会非常慢。考虑到这些接口之间有大部分都是 无前后顺序
简介 waynboot-mall 是一套全部开源的 H5 商城项目，包含运营后台、H5 商城前台和后端接口三个项目 。实现了一套完整的商城业务，有首页展示、商品分类、商品详情、sku 详情、商品搜索、加入购物车、结算下单、支付宝/微信支付/易支付对接、我的订单列表、商品评论等一系列功能 。
前言 我之前在一家餐饮公司待过两年，每天中午和晚上用餐高峰期，系统的并发量不容小觑。 为了保险起见，公司规定各部门都要在吃饭的时间轮流值班，防止出现线上问题时能够及时处理。 我当时在后厨显示系统团队，该系统属于订单的下游业务。 用户点完菜下单后，订单系统会通过发kafka消息给我们系统，系统读取消息
在进行BI系统搭建之前，有两个问题一定是大家思考最为深入的： 1、 为什要搭建BI系统？ 2、 搭建BI系统能解决什么问题？ 我们搭建的信息化系统运行了一段时间之后，来自各个业务系统的订单、库存、交易账目、客户和供应商等都会积累产生大量数据，来自企业所处行业和竞争对手的数据以及来自企业所处的其他外部
今天想聊一下分库分表，因为对于快速增长的业务来说，这个是无法回避的一环。之前我在做商城相关的SAAS系统，商品池是一个存储瓶颈，商品池数量会基于租户增长和运营变得指数级增长，短短几个月就能涨到几千万的数据，而运营半年后就可能过亿。而对于订单这种数据，也会跟着业务的成长，也会变得愈发巨大。
作者：京东零售 李孟东 00 导读 企业前台研发部包含了企业业务大部分的对外前台系统，其中京东VOP平台(开放平台)适合于自建内网采购商城平台的企业客户。 京东为这类客户专门开发API接口，对接到客户内网的网上商城，将产品SKU直接推送到客户内网，客户内部采购人员可以直接在内网商城进行下单采购，订单
你好呀，我是歪歪。 前几天遇到一个生产问题，同一个数据在数据库里面被插入了两次，导致后续处理出现了一些问题。 当时我们首先检讨了自己，没有做好幂等校验。甚至还发现了一个低级错误：对应的表，针对订单号，这个业务上具有唯一属性的字段，连唯一索引都没有加。如果加了唯一索引，也不至于出现落库两次的情况。 然
会员制的订阅付费在影音娱乐行业中已相当普及，近几年，不少游戏厂商也开始尝试订阅收费模式。在分析具体的用户订阅偏好以及订阅付费模式带来的增长效果时，我们常常会有这些疑问： 如何从用户的整体付费行为中具体拆解订阅付费事件并分析？ 想要了解当前应用内用户的整体订阅概况？ 订阅用户和非订阅用户在留存与付费偏
# 一、简介 订阅发布模式（Publish-Subscribe Pattern）是一种行之有效的解耦框架与业务逻辑的方式，也是一种常见的观察者设计模式，它被广泛应用于事件驱动架构中。 在这个模式中，发布者（或者说是主题）并不直接发送消息给订阅者，而是通过调度中心（或者叫消息代理）来传递消息。 发布者
目录 1、发布订阅 1.1 什么是发布订阅 1.2 客户端实例演示 1.3 Java API演示 1.4 Redis发布订阅和rabbitmq的区别 2、批量操作 2.1 普通模式与 PipeLine 模式 2.2 适用场景 2.3 源码解析 2.4 Pipelining的局限性 2.5 事务与 L
事件回调 订阅事件后，开放平台将会在事件发生时（如：机器人入群）向请求网址推送消息。 钉钉三方企业应用事件与回调配置界面如下： 推送方式有三种： Http 推送（官方不推荐） SyncHttp 推送 （官方推荐） RDS 推送（官方推荐） Http和SyncHttp没有太大的区别，按钉钉的说法是：与
在集成和调试订阅型商品时，我们会依赖沙盒环境来进行模拟实际场景。 订阅型商品的购买流程和一次性商品的购买流程类似，但订阅还有其他细节场景，比如续订成功或失败，续订周期时长等。沙盒环境下的订阅续订时间会比正常情况更快，引入“时光机”概念帮助您快速测试您应用的订阅场景。比如订阅周期为1周，商品在3分钟后
自从开始搞YouTube中文配音以来，我们一直是7*24小时，夜以继日的在批量处理一些优质的学习资源，一方面是翻译，另一方面是配音。这样用户在打开的时候，就能获得经过我们优化的翻译和配音了。 这次我们刚刚处理完一个油管上非常火爆的IT类学习频道：Edureka。 该频道内全是IT行业的免费学习视频
Combine简介 Combine是一个苹果用来处理事件的新的响应式框架,支持iOS 13及以上版本。 你可以使用Combine去统一和简化在处理类似于target-action，delegate，kvo等事情的代码。 iOS目前已经有第三方的响应式框架了，如：RxSwift、ReactiveCoc
这篇文章，笔者想聊聊 RocketMQ 最佳实践之一：保证订阅关系一致。 订阅关系一致指的是同一个消费者 Group ID 下所有 Consumer 实例所订阅的 Topic 、Tag 必须完全一致。 如果订阅关系不一致，消息消费的逻辑就会混乱，甚至导致消息丢失。 1 订阅关系演示 首先我们展示正确
定义 发布订阅模式是基于一个事件（主题）通道，希望接收通知的对象Subscriber （订阅者）通过自定义事件订阅主题，被激活事件的对象 Publisher （发布者）通过发布主题事件的方式通知订阅者 Subscriber （订阅者）对象。 简单说就是发布者与订阅者通过事件来通信，这里的发布者是之前
自托管模式运行dapr 新建订阅webapi项目,取名为backend 项目增加docker支持，取消https支持 修改Program.cs var builder = WebApplication.CreateBuilder(args); builder.Services.AddControll
