1.业务价值->承载高并发->性能优化。一切的前提是业务价值需要。如果没有足够的价值，那么可读性才是第一，性能在需要的地方是no.1，但不需要的地方可能就是倒数第一稞。当下技术框架出来的软件差不到哪去，没有这种及时响应诉求的地方，削峰下慢慢跑就是了。（工作需要，常在缺少价值的地方着手性能优化，让我对这种就为个数字的操作很反感。要知道，异步，并发编程，逻辑缓存，算法真的会加剧系统的复杂度，得不偿失。如果没那个价值，简单才是王道）

2.提高并发度。要么加硬件，要么降低服务响应时间。做为开发，我们的目光更聚焦在降低响应时间这块。
1.采用非阻塞的rpc调用（高效的远端请求模式，采用容器的覆盖网络我认为也算）
2.将计算密集和io密集的的逻辑分割开，单独线程池，调整线程比例压榨单机性能（或者说找拐点）。
3.做缓存，io耗时的缓存和计算耗时的缓存（多级缓存，数据压缩降低带宽）。
4.采用享元模式，用好对象池和本地线程空间，尽量减少对象创建与销毁的开销，提高复用。
5.业务拆分，像状态变化后的外部系统通知，业务监控，es或solr等副本数据同步等操作，无需在主流程中做的事都拆掉。走canal监听表数据变化，推mq保最终一致的方式从业务项目完全解偶出来。
6.fork_join，分而治之的处理大任务。并发编程，采用多线程并行的方式处理业务。（规避伪共享，减小锁力度，采用合适的锁）。
7.数据库配置优化，查询优化。（存储优化比较头疼，毕竟不按业务拆单点跑不掉，单点性能就要命。基本只能内存库先行，后台同步数据做持久。然后内存库多副本，自修复，保留一系列自修复失败的修复手段）

高并发：高性能（响应时间）、高可用（down机、故障、维护）、可扩展（应急扩容）
响应时间（平均值、最大值、分位值），响应为1s，吞吐量为每秒1次，响应缩短到10ms，吞吐量上升到每秒100次，从用户体验来说：200ms分界点，1s为另一个分界点，健康系统的99分位值的响应时间控制在200ms以内，不超过1s的请求占比要超过99.99%
高并发下的性能优化手段：
1.提高系统的处理核心数（吞吐量=核心数(并发进程数)/响应时间(s)）
  但并非无限增加核心数就可以增加吞吐量，随着进程数增加，并行的任务对于资源的争夺也增加，在某
  个临界点，进程增加导致系统的性能下降，这就是性能测试中的拐点模型，所以在评估系统性能时，需要做压力测试，找到拐点
2.减少单次任务响应时间
cpu密集型：优化算法
io密集型：1.采用工具，linux的工具集
              2.通过监控，对任务的每一个步骤做分时统计，从而找到任务中哪一步小号消耗了更多的时间

既然老师愿意把这门课做好，作为学员提几点建议：
1.每一章都会有一个中心，几个侧重点，建议关键部分文字加粗或者字号加大一点，让重心更醒目。一遍看下来，几乎啥都没记住。
2.条理清晰，有时候你会发现，用1.2.3这种编号作用非常明显。这点得到做的挺好的，我都购买的有课程。
3.技术文章，理论讲太多，都觉得是鸡汤，看了就忘，或者说作用不大，理论大家能查阅资料，也算是理解一星半点。大家的问题都在于没把理论作用于实践中，如果每一章讲完理论后能够以实际应用辅助讲一下，可以说事半功倍。
4.我说话很直接，真正的高手也不会购买课程，购买课程的也是大家在这块有短板，希望通过这门课解决一些项目中的问题。按照2/8原则，百分之八十的人项目中都没有大并发，这种系统设计和运用，大家缺乏经验。讲解时候，浅显易懂，案例分享很关键，百分之八十人看懂了，能应用了，那这门课非常成功了。
5.希望高手之间多讨论或者辩论，其实在你们的讨论中，可以学到很多，开拓视野，举一反三。希望评论中只要不是骂人，违反国家政策，涉及到问题本身讨论的，尽量显示出来。