默认在 class 中，一直都是 16(常量)，你 new 的时候只是建立了引用，put 的时候才会真正分配内存空间

一般编排工具都会提供代理的，比如所有 eureka 的 docker 应用都被一个 nginx 镜像服务代理(也可以是多个服务), 这个镜像服务一般都是可固定宿主机 ip 和端口的

间隙锁是为防止幻读，因为 id=3 不存在所以要锁定区间，如果存在就是行锁了

P 不能保证的话那这个分布式还有什么意义，想想一台机器坏了所有服务都不可用，还不如单机呢

在 nginx 中配置 proxy_pass 时，当在后面的 url 加上了 /，相当于是绝对根路径，则 nginx 不会把 location 中匹配的路径部分代理走;如果没有 /，则会把匹配的路径部分也给代理走

泛型 List<T>

顺便用抓包工具看一下 tcp 连接数还有数据包的大小

很奇怪的现象。执行语句的客户端是哪个？ Navicat ？ DataGrip?PLSQL ？

1.别用触发器；
2.考虑做分表；
3.在代码里做好数据的清洗，最好是先删除数据库中较老时间的数据然后再插入，能不用 update 就尽量规避；
4.注意调整 max_allowed_packet 的限制。

严格意义上数据库的 decimal 能够满足需求但是数据处理上比较蛋疼，有条件的话用 bigint 存储分，然后整个后端操作里全都使用分单位,尽量避免小数的出现，唯一的缺陷就是 bigint 比较耗费空间 decimal 在 8 位小数时才用 8 个字节，考虑到分单位可能实际中只需要用 5 个字节，相当于每一条记录多浪费 3 个字节的空间，再加上金额这个字段有很多种，结合下来整体的开销还是不小的。所以这就是个用存储换舒适度的问题。

@jry 你认真的？普通项目能不能活过 6.9 年都是个问题。。。

分布式 id 为什么不用推特的 snow 算法生成，uuid 的缺点太明显了

不难

看下结果集数据量，navicat fetch 的可能不是全部数据。

我司电信项目的并发标准是日常 500qps, 峰值 3 倍也就是 1500qps，实际压测中可以达到 10000qps，当然和互联网公司没得比，真正的互联网公司的高并发至少要 10w 级

从设计模式的单一职责原则来说不建议 service 的互相调用，相似的业务也应该由多个 Dao 重新组合完成实际业务，但是这样会带来大量冗余，好处是各个 service 完全独立没有相互耦合。相对的 service 互相调用则可以使得代码更为简洁业务上的相关性也体现在了代码上，在需要修改时只需要修改被依赖的 service，在重构时有很大的作用。业界对于耦合十分厌恶，比较互联网项目基本都拆除了外键，所以 service 只调用 dao 是一种更严谨的方式，service 之前的相互依赖一旦随着项目推进逐渐增多就会变成项目的负债让项目的推进越来越难。如果项目中没有严格规定的话，要考虑好两个 service 所对应的顶层业务是否需要这种关联性，需要则 service 调用 service，不然还是调用 dao 重新组合业务好了(这种方式调优时也有明显优势)。

instrument、aop、asm、javasist

做 CI 不 pull 怎么行，封版就是让大家过个好年

用 docker 好一点，但也有 windows 的版本