JJXxXLL

经典错误 12345<update id="updateOrderStatus2COMPLETED" parameterType="cc.jxlll.infrastructure.dao.po.GroupBuyOrderList"> update group_buy_order_list set status = 1, out_trade_time = #{out_trade_time} , update_time = now() where out_trade_no = #{outTradeNo} and user_id = #{userId}</update> 123456789<insert id="insert"> INSERT INTO group_buy_order (team_id, activity_id, source, channel, original_price, ded ...

String 还是 Hash 存储对象数据更好呢

1.基础知识1.主键和外键有什么区别?​ 主键是用来唯一标识一条记录的，不能为空也不能重复，一张表只能有一个主键。在 InnoDB 中，主键索引是聚簇索引，数据本身存放在主键索引的叶子节点中。 外键主要用于建立表与表之间的关联关系，用来约束子表中的字段必须来自于父表的主键或唯一键，从而保证数据一致性。外键字段可以重复，也可以为空，一张表可以有多个外键。 在实际生产环境中，一般不直接使用数据库外键，而是在业务层通过逻辑外键来维护数据一致性，以避免外键带来的性能开销和维护复杂度问题。 2.为什么不推荐使用外键与级联？外键和级联主要用于在数据库层面保证数据一致性，但在实际生产环境中通常不推荐使用。 一方面，外键和级联在插入、更新和删除时会带来额外的性能开销，尤其是在高并发场景下影响明显；另一方面，级联操作存在较大的误操作风险，一次错误删除可能导致大量数据被级联删除。 此外，外键不适用于分库分表和微服务架构，会增加系统的耦合度和维护成本。 因此，在实际项目中通常采用逻辑外键，在业务层通过代码和事务来保证数据一致性，而不是依赖数据库外键和级联机制。 什么是存储过程存储过程是一组预先编译并 ...

IoC有什么用？ 第一层（核心定义）：“IoC将对象创建和依赖管理的控制权从程序代码反转到容器，实现了解耦。我的类不再new依赖对象，而是通过构造器、Setter或字段声明它需要什么，容器在运行时注入给它。” 第二层（具体价值）：“它带来了四个关键好处：第一是解耦，让我的业务代码只依赖接口，便于替换实现。第二是易于测试，我可以轻松注入Mock对象进行单元测试。第三是集中管理，所有对象的生命周期由容器统一管理，更安全。第四是配置灵活，通过修改配置就能改变组件行为和依赖关系。” 第三层（结合实践）：“比如在我的项目中，OrderService依赖PaymentService。利用IoC，我只需用@Autowired声明依赖。当需要从微信支付切换到支付宝时，我只需配置不同的PaymentService实现Bean，OrderService的代码一行都不用改，这极大地提升了维护性和扩展性。”

MySQL 1234567<update id="updateAddLockCount" parameterType="java.lang.String"> <![CDATA[ update group_buy_order set lock_count = lock_count + 1, update_time= now() where team_id = #{teamId} and lock_count < target_count ]]></update> 责任链模型结构

为了拆分库表，为了省事在xml文件中直接注释： 12345678910 <select id="queryValidGroupBuyActivityId" resultMap="GroupBuyActivityMap"> SELECT activity_id, activity_name,-- source, channel, goods_id, discount_id, group_type, take_limit_count, target, valid_time, status, start_time, end_time, tag_id, tag_scope FROM group_buy_activity-- WHERE source = #{source} AND channel = #{channel} WHERE activity_id = #{acti ...

👍 很好，这一步你已经精准定位到“真正的根因”了。而且这个问题非常典型、非常高级，不是新手能一下子意识到的。 我给你把这件事一次性讲透👇 一、结论先行（你这次为什么会 NPE） ❌ 不是 SQL 查不到数据 ❌ 不是多线程问题 ✅ 是 MyBatis 映射方式用错了：resultType vs resultMap 你原来的 SQL 能查到行，但是 MyBatis 没有把字段正确映射到 Java 对象里，导致： 123groupBuyActivityRes != null但groupBuyActivityRes.getDiscountId() == null 于是后面必炸 💥 二、你现在这两段 SQL 的“本质区别”❌ 原来（有问题的）12<select id="queryValidGroupBuyActivity" resultType="cc.jxlll.infrastructure.dao.po.GroupBuyActivity"> ✅ 现在（正确的）12<select id="query ...

设计模式 先看左侧， 1234策略路由抽象类 AbstractStrategyRouterT 入参类型D 上下文参数R 返参类型 1234567891011121314public abstract class AbstractStrategyRouter<T,D,R> implements StrategyHandler<T,D,R>,StrategyMapper<T, D, R> { StrategyHandler<T,D,R> defaultStrategyHandler = StrategyHandler.DEFAULT; public R router(T requestParameter, D dynamicContext) throws Exception { StrategyHandler<T,D,R> strategyHandler = get(requestParameter, dynamicContext); if(null != strate ...

新增TagNode节点，进行过滤：过滤逻辑： 没配置tag_id，就是不筛选人群，所以用户全都可见可参与；配置了tag_id，就是要筛选人群 如果用户在人群标签中直接放行，可见可参与；不在此人群标签中要看tag_scope的配置 如果tag_scope为空就是不做限制，所以也全都可见可参与；如果tag_scope有值，则代表做限制 包含 “1” → 不可见（visible=false） 包含 “2” → 不可参与（enable=false） 动态配置开关操作何不停车就给汽车换个轮子？ 这是互联网应用程序中经常干的事情，在程序运行过程中，直接动态变更某些属性配置。这些动态变更的配置包括降级和切量的开关，也包括一些功能程序的白名单用户测试。 那么对于配置中心，有 SpringCloud Config + Event Bus，也有 Nacos，还有各个大厂中会基于各类组件做的自研实现。那么本节我们先来做一个基于 Redis 发布/订阅处理动态配置的自研的实现，之后对于 SpringCloud 的动态配置变更已经有案例，小伙伴也可以学习。 1.引入两个概念:降级和切片 ...

a

你这个描述非常关键，而且我可以明确告诉你一句话： 你之前的 Git 使用流程在“逻辑上是错误的”，但 Git 又“纵容”了你，所以才会出现现在这种看似诡异、其实完全可解释的结果。 我按 发生了什么 → 为什么会这样 → 正确理解 → 如何补救 给你一次讲透。 一、先给你一句“定性结论”（非常重要） Git 从来不会“推送未提交的代码”。你之前那些“只 push 不 commit 的分支”，实际上远程什么都没保存。 二、我们把你之前的真实流程“还原一遍”（这是关键）你说你的流程是： 从 master 新建分支 A 在分支 A 写代码 ❌ 只 push，没有 commit 再从 master 新建分支 B 发现 B 里居然有刚刚写的代码 重复这个流程很多次 最后一次：在某个分支 commit + push 再从 master 新建分支，发现之前写的内容全没了 👉 这一切，其实完全符合 Git 的工作原理 三、关键真相 1：你之前写的代码，从来没进过 Git 历史Git 的铁律（请牢牢记住）1❗ 没有 commit = Git 当作这段代码从未存在 你之前做的其实是： 写 ...

公众号扫码登录 用户在网页点“微信登录”，网页先去你服务端要一个“登录二维码”。你服务端为了能调用微信接口，先拿（或从缓存取）公众号的 access_token，然后调用微信的“创建带参数二维码”接口 /cgi-bin/qrcode/create，把一个你生成的参数（通常叫 scene，你可以理解为一次性的 ticket/登录编号）塞进请求里。微信返回一个 ticket（以及过期时间），网页拿到这个 ticket 后，不是让你服务端自己画二维码，而是直接用微信的展示地址 https://mp.weixin.qq.com/cgi-bin/showqrcode?ticket=xxx 当作图片链接显示在 <img> 上，浏览器就能看到二维码了（注意这个接口返回的是图片二进制，不是 JSON）。 接着用户用微信扫码。扫码后微信会把这个二维码里携带的参数（EventKey，就是你当初的 scene/ticket）连同用户身份（FromUserName，也就是 openid）以 XML 回调到你配置的公众号服务器地址。你服务端收到回调后，做一件最关键的事：把 ticket ↔ ope ...