@promontory123 机器是索尼 a6100 ，镜头一个是索尼 55-210 长焦，一个是永诺 50 1.8 的人像

@hsuvee 哈哈，好多人啊

遇到过两次阿里云 oss 被刷的情况，两次都是同一张图片，告警之后立刻关闭了该图片的访问权限，访问会报 403 ，几分钟后流量归零。
我至今没搞懂为什么刷我，而且两次刷的都是同一张图片。

首先这个事儿跟会不会说话没半毛钱关系，只能说你和公司没有做好预期管理。
你公司以为可以白嫖你账号，你以为当个中间商赚公司一笔，就这么简单。

我以为“防御性编程”只是一个梗，难道真的有人这么写吗？

本质上来说无论用什么语言编写的程序，最终都可以编译成二进制可执行文件并在设备上运行，我认为从技术上来讲并不存在只有哪个语言可以做，哪个语言不可以做的情况。
之所以选择用 Java 开发 Android 是因为 Java 在端上运行有一些其他语言不具备的优势，最主要的就是有 JVM 的存在，Java 以“一次编写到处运行”而著称，这个特性在小型终端场景的优势尤其明显，可以让应用层开发可以尽量少的关注底层设备的差异，毕竟 Android 设备的型号架构可能千差万别，甚至于说最初 Android 是给数码相机开发的操作系统你敢信？

第一个思路是验证是否走上了代理。可以看看代理的日志。
还可以对比一下公司电脑和家里电脑上代理的配置有什么不同，例如是不是 TUN 模式之类。
另一个思路是就在代码中手动配置使用代理。

查问题困难问题出在没有统一规范吧，如果各服务有统一的输入输出标准和监控项，加上链路追踪，起码可以快速定位到是哪一个服务的哪一个接口出问题

@yuzo555 仅仅添加了根证书是不会解析到 HTTPS 数据的，想要解析出 HTTPS 数据还需要有劫持网路流量这一步，让所有请求都走代理，这就形成了典型的中间人。

我认为是的，这么说吧如果是一个全新项目不需要考虑兼容已有的代码和库，肯定是首选协程。
至少没遇到过能用协程而不用，反而选择用多线程的情况。

@HFX3389 贵是贵但也没办法，arm 版 Mac 已经不能扩容内存了，16G 绝对后悔。

别买 16G 内存就行了，根本不够用。

朋友你可能想多了，按照你这个代码出事了我给你担责任

有两种路线我比较认可：

一种是边学边用，边踩坑边理解。
这种机会一般只存在初创公司不断发展壮大的同时业务系统也在逐渐迭代升级的过程中，而且业务能在几经折腾之后还能存活下来的，只能说可遇不可求。

另一种是抓住几个经典的成熟系统深入研究横向对比反复蹂躏和被蹂躏，从中汲取系统设计的真谛。
我推荐楼主试试第二种方式。

在我看来应对高并发场景的核心要义是「消除单点」+「状态同步」两手抓。消除单点意味着分布式，这样可以提高系统可用性和吞吐量，而一旦引入了分布式就涉及到节点之间的状态同步问题，状态同步意味着系统中数据要保持某种程度上的一致。最理想的系统肯定是任何时刻都可用，且任何地点读取到的内容都一致，但鱼和熊掌不可兼得，如何在这两者之间寻找一个平衡就是不同项目的差异点，由此才引申出不同项目的特点和适用场景。

例如 InnoDB 为了支持读并发采用了 B+树、Buffer Pool 和 MVCC ，为了支持写并发采用了行级锁，而在单机性能达到瓶颈之后自然会演进到集群架构，也就是消除单点；主从架构中必然涉及到主从节点间的数据同步，如果数据同步采用全异步策略那么性能最高但安全性最差，反之如果采用全同步策略那么性能最差但安全性最高，系统设计一直都是在取舍。
再例如 Redis 全内存操作保证了其性能的底线，而为了在性能和内存占用之间作取舍，Redis 针对不同数据量级设计了不同的数据类型。当单机达到瓶颈之后也自然演进到分布式架构，集群架构思路是分片，而每一个分片之内又是一个主从来提高可用性；如果主从复制完全是异步的，那肯定存在数据丢失的问题，所以用 Redis 的 setnx 方式做分布式锁是存在隐患的，基于此 Redis 提出了 Redlock 算法处理分布式锁。另一种实现分布式锁的方式则是使用 zookeeper ，因为 zookeeper 实现的 ZAB 协议要求多数节点提交才确认成功，同时提供 sync 同步读保证顺序一致性，不过这样的话相对 Redis 性能就差一些。
除了架构上的取舍，在业务上也可以做调整，例如是否真的有必要把所有请求都打到同一组集群上吗？是否可以按业务、地区等维度拆分成不同集群，不同集群各自处理各自的流量，并发也就降下来了，也就有了更多调整空间。这符合康威法则的思想，即组织架构能够影响软件架构。
还有比如能否将数据放在离用户更近的地方？这样用户访问的路径就更短体验更好，服务也因为只需要服务一部分用户从而吞吐量更高性能更好。这也是空间换时间在分布式场景下的应用。
另外系统本身也需要保护，谁还不是个宝宝了，不能来多少流量就放多少流量进来，系统挂了谁也别玩了。这就涉及到限流、降级、熔断等保护后端的措施，所以服务状态监控、告警和自动扩缩容的需求也被提了出来，不过这里更偏向于基础设施和运维侧了。

总之面对高并发场景所面对的问题大体上都是相似的：高可用，高吞吐量，事务和一致性；而解决办法也都类似，在实现过程中不断做取舍：分层、缓存、复制和分片、共识算法思想及实现。学习过程中常常问问自己，这个系统是如何保证高可用和高吞吐的？是完整支持事务还是部分支持事务？以及如何实现事务？做出了什么级别的一致性保证并且如何实现的？

最后也推荐 ddia 《数据密集型应用系统设计》一书，我认为是程序员必读书目之一，值得多读几遍。
附上一个之前写的读书笔记 https://www.lipijin.com/reading-notes-ddia

我更倾向于不加任何干预，就是纯粹的根据用户行为做排行依据，但我是从电商角度出发，如果是内容产品可能会有跟多考虑。

如果希望做到有倾向性的内容展示，可以对某些类别或标签做降权甚至不进入榜单。

从产品角度还可以做成细分类别的热榜，这样就不会出现热榜中充斥着某一类或某几类的内容。

@waytodelay 没有人说其他接口啊，我怀疑你没搞清楚 tp999 的含义。总之这种现象出现并不奇怪，从你发出请求到你接到对方的响应，这中间涉及到很多环节，存在时间差是正常的，如果出现时间差相差非常多那一定是中间环节有异常导致的，可能是线程满了在排队，可能是 gc 了，可能是网络波动，可能是系统资源不够了等等。系统方面就得结合系统的监控看是不是配置不够了，网络丢包率之类的。服务内部的话很可能是线程问题或者 gc 了，可以加链路追踪 id ，然后日志打点收集，复现的时候对比看。

@waytodelay 我说的就是一个接口的 tp999 ，基本相当于这个接口的全部请求了。