看上去是 lz 测试问题。手头笔记本和台式机打开资源管理器都很快，无论什么打开方式，几年前的机器。win10 很早就开始用了，速度一向没有问题

年报统计 5 分钟刷一次？定这技术需求的人是不是从来没有做过 OLAP ？月报年报根本不可能是实时报表，都是定期任务，明细数据输入截止后执行一晚上，第二天就能看所有报表了，即使单表上千万也足够。上亿数据就得用大数据计算框架，Spark/Flink 等都可以，但这得准备很多硬件资源

@frozenway 年花费 20 万不是大客户但应该也不算很小了，如果通过代理商注册，代理商应该是有可能给你安排专门渠道的技术支持，不过日常推销也会比较多

@fengmumu 客户分级服务是很正常的经营行为，工单就是非快速服务，也没有说不理你，在小服务商那你不花钱也可能得到分钟级响应。只是没有得到阿里云的效率服务，为什么要自轻自贱骂自己是垃圾？

我用清除大法就好了

docker 部署还纠结镜像的操作系统？从安全角度，生产环境镜像一般不都是精简版吗？各个开发平台都是 slim/alpine 这样的，alpine 应该是最小的。用 centos 是打算发一个几百 mb 的大镜像？

@bclerdx 买几百 1 年主机这样的人很多，不太可能遇到付费技术支持才能解决的问题，1 年几百上千的花费也不太可能愿意花近 180 元就 3 个工单费用

工单付费也是一种客户筛选，看上去阿里云是想通过工单付费来过滤掉一些付费意愿低但想要优先服务的群体。阿里云现在国内市场份额很高，从运营角度确实可以选择目标群体了。如果不能自助解决，只能换到其他云。

面试官问出这么水的问题，你还想去这样的公司吗

死锁通常都是代码逻辑问题。估计你们的 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 的证明。不好好研究学术，非得来指导工程实践，脑子有问题