死锁通常都是代码逻辑问题。估计你们的 HIS 有些操作是跨好几个表的事务，可能是部分表数据量大了，事务运行时间较长，且事务中还有查询操作，这样在大量请求并发时，很容易产生表锁竞争导致死锁。建议按以下排查
1 、死锁表的数据量是否较大，代码中的 sql 是否较慢，数据量到几百万上千万或更多，优化索引，同时考虑做分区或分表
2 、检查代码中的跨多表事务，尽量在事务外做查询，尽可能减少跨表事务的数量，尽可能缩减跨表事务的跨表范围，整体上降低多表锁竞争的概率
3 、没有触发器和存储过程是最好，有的话都改在代码里实现。这 2 个都是测试困难户，写在数据库里很容易被忘记，也容易让数据产生代码预期外的结果。喜欢存储过程的人倾向写很长跨多表的存储过程，调试起来及其麻烦，且高并发时非常容易产生死锁

性能优先选 Kafka，有事务需求选 rabbitmq 。除非用 Spring Alibaba 那一套，否则不会考虑 rocketmq，http 协议才有多语言 sdk，生态差太多了

数据可视化的目标群体都是商用，需要有稳定的技术支持，所以能做长久的都是有限功能免费版加全功能商用版，如果需求不复杂，应该可以找到满足需求的免费版

@wdhwg001 你用云服务只是当网盘？整体不都要考虑么？网络异常不能访问数据，数据损坏也不能访问数据，你做云服务会遇到各种原因的可用性问题，而且数据本身的可靠性有跨数据中心或跨地区冗余就可以保证，云厂商技术运维服务能力也是因素之一，在我看来只考虑某个服务的 SLA 没有意义，如果真的在意 SLA 多几个 9，选择云服务就没有必要把 9 少的放进比较列表里

@wdhwg001 你自己按个计算器就知道小数点后面 5 个 9 是全年只有 5 分钟服务不可用，你觉得那么多服务能做到小数点后面 6 个 7 个 9 可信吗？ 4 个 9 也只是全年 52 分钟不可用。一般通报一次网络线路故障就超了

lz 都没有搞懂 serverless 的正确定义就在下结论。一个平台，从开发者角度基础设施是透明的，才是 serverless，你说的只是 stateless

@abersheeran 我个人觉得 429 是对善意使用的响应，对于恶意访问这响应的含义太温和了，retry-after 都不能给

不借助其他组件，那么在应用内用限流，通常是 AOP 或请求处理中间件的开发模式，判断单一来源请求数在一个时间范围内超过阈值就中断后续处理，直接返回 HTTP 响应码 403

测试驱动开发（英语缩写 TDD ）以国内的行业习惯应该很难贯彻的。我现在的项目主要都是写 web API，控制器里的代码很少，基本没有单元测试。控制器调用的方法中会选择一些业务逻辑处理占比较高的做单元测试，CRUD 比例高的方法就忽略了，业务逻辑比例高的方法一般都是关键代码，所以需要靠单元测试保障，重构时也容易做回归测试。

@v2Geeker lz 完全不对，他根本没有给出必须 zk 的理由。他骂街式口吻以工程应用角度提出质疑，却以理论推导来反对其他人以实际使用为论据的反驳，根本就是牛头不对马嘴，他完全就是为了反对而反对。为了反对而举的例子也是可笑至极，1000 万美金订单会因为 redis 分布式锁的低概率潜在问题而丢了根本就是系统设计错误，能有 1000 万订单的分布式系统一定会有多重机制保障的设计。别人反问他是否会以分布式锁做最终判定，他还死鸭子嘴硬，他就会。最终还是没有给出必须用 zk etcd 的证明。不好好研究学术，非得来指导工程实践，脑子有问题

学好了，可以去微软工作

移出使用的代码，有 release 包含相关代码的，删除这些 release，这样你可以仍然保持 Apache 许可

@littlewing 足额是指按实际薪水作为缴费基数，比例各地不同，有的是区间，可以按比例下限

我觉得好多人因为 jwt 有无状态这个特性很纠结，好像非用这个特性不可，而忽略其他重要的特性。如果你深入看 jwt，就能理解 jwt 的无状态只是一个附带的特性，不是主要特性，是可以做成服务端无状态，而不是必须做成无状态

jwt 有很多特性，也许最开始是包含无状态的设计意图，但在我看来这不是它最有用的特性，无状态不符合安全需求完全可以忽略这个特性。

我觉得 jwt 最有价值的特性：可以跨多个域名验证，Web 服务器能以任意网络拓扑结构横向扩展而不影响校验，客户端可以多种方式保存（浏览器 cookie 、HTML 存储对象、APP 用户数据文件等）或发送（ URL 参数、form 表单等）。你当然可以自搞一套来满足这些需求，但 jwt 这样非常细节具体的一个标准很容易进行行业标准化实现，所以网上各种开发平台不同公司和开发者实现的 jwt 类库和产品都是相容的，可以开箱即用，节省大量开发成本。

回复的好多人真是死鸭子嘴硬，我错了但我就是不改，你纠错就是秀优越感