2019-09-18martin fowler好像曾经说过，能使用单体解决的问题，就不要采用分布式。不能为了技术而技术，采用分布式固然可以分流用户请求，提高系统的响应能力，但同样也带来了复杂性。软件开发最终的目的是商业利益。非常赞成老师的观点，罗马城不是一天就建立起来的。架构的工作应该是阶段性，解决阶段性系统的复杂性。如果单体跑的很好，或者通过scale up方式在成本可控的情况能解决就不要想着诗和远方，因为系统内部的进程间调用，肯定比不同物理机的进程之间调用要快。作者回复: 说的真好！
1 65
2019-09-18之前做的创业项目也是遇到盲目优化的问题，系统最核心的撮合结算服务，刚开始只能100次每秒，后来为了优化到百万级，花了大量时间研究各种方案，做了大量的性能测试，耽误了很长时间推向市场，结果最终优化到了不到一万tps，但后面真正上线的结果可能不到也就100tps，所以真正的需求是市场需求，不是一开始就冲着最牛逼的方案搞，线上的需求远比一开始的预想复杂，没足够的资源和动力，绝对不要折腾，不过时刻准备好可能会出现的瓶颈是必要的，免得半夜宕机，慌得一比 2 19
2019-09-19代部落伙伴问个问题：关于秒杀这种场景我想的是用redis的list不就完全可以实现吗。活动开始前，先把要抢的N个商品push到list中。活动开始后，每来一个请求就从list中pop一个商品出去，当list为空后直接返回“已抢光”的响应，由于可秒杀的商品数量并不多，能通过的请求也可以采用同步的方式进行，这样不是既简单又快速。可是我搜了一下网上的方案，都特别的复杂，请问这种方式有什么问题吗？作者回复: 这个商品应该是放在单一的redis节点里面的吧，放在多个节点里面不好维护一致性。那么如果在流量或者带宽方面超过单个节点的限制咋办？是否要考虑动态和静态数据的隔离？是否要考虑降低redis的写流量峰值？所以流量大了，自然方案就复杂了~
14 13
2019-09-18高并发除了横向扩容，缓存和异步化，系统还需要做好保护，比如限流降级，过载保护。甚至高并发的问题更是一个系统性问题，从前端到服务端，从产品设计上都要考虑进来。不过这块就比较业务化了，不是常规的操作 3 12
2019-09-18架构设计的过程中要识别每个阶段的复杂度，有针对的做架构设计。避免过度设计带来的成本上升。这个原则和李运华老师的架构课讲的架构设计的原则不谋而合。😄 10
2019-09-18老师讲得很好！不过，还是觉得偏理论较多。例如，讲到踩过很多坑，这些坑没有一些案例说明和后来的解决问题方案。比如，之前负责的支付系统项目，在流量不是很大的情况下，就引入了zk集群(3台)zk集群所在的线上服务，存在一台宕机，整个线上支付都不可用。后面解决：只好切回单体服务作者回复: 后面课程会有一些关键知识点的案例介绍的
8 9
2019-09-19现阶段大多数公司其实都没机会碰到高并发。很多时候我们学习它，只是为了将来有一天要用到时候不会一脸懵。继续学习～期待以后的精彩分享 7
2019-09-181.技术在不断演进，演进的目的和内驱动力是解决当前系统存在的问题，过早过度设计大多只会延误系统的发展。一切都以实际情况和需要出发，一步步优化，一步步演进，个人能力提升也是同样的道理。
2.高并发系统设计通用方法:水平拓展，缓存，异步。这只是指导思想，如何更巧妙的运用才是最具魅力的。作者回复: 说的真好！
7
2019-09-18我们公司一开始就采用了微服务架构方案，但在实施过程中却缺乏架构演进和优化过程，在支撑业务的同时也造成了很多运维和技术痛点 7
2019-09-19讲得真好！小建议，对于一些关键的术语可不可以像我们讲scale-out一样，同时使用中文和英文呢？比如cache，async，这样可以方便将来同时查阅中英文文献。作者回复: 好嘞，以后我会注意的：）
4
2019-09-18老师，你把“缓存”比喻成“拓宽河道”，个人觉得是不妥当的，应是建水库更好些。拓宽河道比较类似Scale-out作者回复: scale-out可以理解为引流和分流；缓存的作用是提速，拓宽河道的作用也是提速，所以有一些的关联
3 4
2019-09-18目前的芯片技术已经到达5nm级别了，最近台积电生产的高通骁龙875，使用的是5nm工艺制造，晶体管密度提升到1.713亿/mm²（这个数据看到时也惊讶到了），比7nm提升70%左右，大概2021年的手机上会普遍起来。作者回复: 优秀！这个我确实没有了解很多，感谢提醒：）
1 4
2019-09-24老师，消息队列用到缓存，之前没有听说过这个，请问哪种消息队列用到缓存？作者回复: 内部实现会用到缓存的思想，Kafka会用到pagecache
3
2019-09-18微服务不是架构演变的终点！
https://mp.weixin.qq.com/s/TAHtAreMkxjWLfW1jSP88w作者回复: 架构演变是没有终点的：）
5 3
2019-09-27老师，多级缓存中，redis层的好处理，但是Nginx缓存，tomcat本地缓存，都是多台机器分布式部署，该如何及时主动更新作者回复: 比如说如果要更新缓存就向一个消息队列里发一个消息，tomcat消费消息后清除本地缓存。不过更多的是等待缓存自己过期，或者定期更新缓存
2
2019-09-26谢谢老师分享。
系统设计的时候，不能一心求大，而是应该有多少人做多少饭，避免不必要的浪费。
拿做饭举例，假设现在有1口锅，可以一次给10人做饭。
突然有一天要给100人做饭，
scale-out，扩展到10口锅来做饭；
缓存，1口锅在人来之前做10次；
异步，人来了，让大家先等着，做饭给大家端过去，不要在都在锅边等着。展开 4 2
2019-09-20为什么说缓存是拓宽河道呢？作者回复: 拓宽河道可以认为是加快水流速度，和缓存加速的思想差不多一致
2
2019-09-18把缓存比喻成拓宽河道不合理。从另外的角度来看，拓宽河道就是增加流量的带宽。这跟缓存放在一起说感觉让人对缓存有误解。作者回复: 当时考虑的是拓宽河道是让水流更快，和缓存思想比较接近
3 2
2019-09-18我更喜欢从成本和用户量的角度去考虑架构的实现方案，细想一下，正好迎合了老师的循序渐进。 2
2019-09-18Scale-out 横向扩展
Scale-up 纵向扩展 2