fyn

目录 * 1 前言 * 2 基础功能：建券发券用券 * 2.1 基础信息：coupon表 * 2.1.1 过期类型与过期时间 * 2.1.2 优惠类型与优惠参数 * 2.1.3 总数量与发放数量 * 2.1.4 SN的作用：安全无小事 * 2.2 用户领到的券：user_coupon表 * 2.

目录 * 1 消息投递：Exchange & RoutingKey * 2 消费消息：Queue * 3 路由规则：Binding * 3.1 如何两个业务消费相同的消息？ * 3.2 一个队列也可以订阅多种消息 * 4 特殊Exchange（default） * 5 无法路由 消息投递：Exchange & RoutingKey 在投递消息时需要指定exchange和routingKey，而不是指定队列名。 在投递消息时和kafka、rocketmq不同，消息并不是通过客户端投递到Queue中的，而是投递到Exchange，

StringBuilder线程不安全。 StringBuffer线程安全。 如果多线程同时构建一个字符串，应该使用StringBuffer，但是什么时候会多线程去构建同一个字符串呢？

在做一些生成代码或生成配置时经常会遇到命名格式不一样的问题，比如有的地方要用驼峰命名（比如代码的类和遍历），有的地方要用下划线命名（比如数据库字段）。因此写了个小工具来快速将一组单词转换成特定格式的命名。 因为我的使用场景中没有太严苛的性能要求，所以里面用到了正则，并且应该也不是最优解，所以不建议在高并发的场景用（也没做过性能测试）。 在查规范的时候学习到了一些有意思的单词，很形象的形容了命名格式。 比如下划线命名是snake，纯大写的下划线命名（比如常量定义AAA_BBB_CCC）是screaming snake（尖叫蛇）。 大驼峰是pascal（这个其实不太理解为什么是帕斯卡）。 用横线命名（比如url、域名、docker服务名：aaa-bbb-ccc）是kebab（烤肉串）。 <?php /** * Created

目录 * 1 数组 * 2 根据Key定位到数组 * 3 处理碰撞的问题 * 4 效率与扩容 * 5 附：完整实现 数组 HashMap底层本质上是一个固定长度的数组 根据Key定位到数组 HashMap的“hash”其实就是对key做哈希，比如将所有字符的charCode加起来然后再除以数组长度后取模（只是举个简单的例子，比一定要用这种算法，无论用那种算法，都会尽量保证当key足够多时，哈希后的结果能正态分布）。这样无论传什么key最终都会被转换成某一个数组下标，并且相同的key两次调用时获得的数组下标肯定是一样的。 class HashMap { /** @type {*[]} */ _array = []; /** @type {number} */ _size