公司组织工程师培训课程，首先是沈老师第一讲“互联网架构入门”。将重点内容简单整理如下。
一、一切脱离业务的架构设计 都是耍流氓
Case1 Redis Or Memcache？
记得面试的时候，沈老师就问过我这个问题
用redis ，为什么要用它？
为何不选择memcache？
结合什么业务场景，可解决什么问题？
一般coder只能回答公司用，领导用，所以用，并未从使用者、架构师的思维去思考这个上述问题。回答这个问题首先除了了解Redis 和 memcached各自特性之外，更需要结合自身业务场景。ps：既然聊到这，便再review一下两款缓存技术的差异：
1、如果需要缓存能够支持更复杂的结构（string、hash、list、set、sorted set）和操作，那么Redis会是不错的选择；
2、使用简单的key-value存储的话，Memcached的内存利用率更高；
3、由于Redis只使用单核（单线程），而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis；
4、Redis中的数据是持久化的，断电或重启后，数据也不会丢失。
5、Memcache做缓存，适合多读少写；Redis在读写效率要求都很高的情况下；
Case2 Mysql 的索引引擎
Myisam和Innodb 均采用B+ tree，而非hash ，但从查询和插入的时间复杂度而言，hash均优于B+树，为何还选择B+tree作为索引结构？
查询时间复杂度 |
插入时间复杂度 |
|
B+ tree |
lg n |
lg n |
hash |
o(1) |
o(1) |
cause 业务需求不可能只是查询id=n条件过滤，更多情况下是使用 time > between等范围查询，这是使用B+ tree 连续（sorted）的数据结构特点，在range查询时效率优于hash；另外磁盘结构针对B tree 更便于存储。
至于为什么更便于磁盘存储读取，详见博客：https://blog.csdn.net/cyl937/article/details/53585007
可以看出，从技术、数据结构设计到具体代码的编写，由大到小说明，架构设计基于业务，是设计，更是随业务发展的演进。其中提到如果回退到4年前公司刚成立时，再来对系统架构进行设计，会是什么样。沈老师觉得还会是当时的样子。架构设计可以想得远，但又不能脱离当下实际想得太远。人生亦是如此。
二、高可用 高并发
1、高可用
何为高可用？线上服务kill 几个，仍持续服务输出，用户无感知，即为高可用。
如何做到高可用？方法论：冗余（集群）、服务检测、流量（故障）转移
从web--nginx--server--cache---db 几个环节对高可用进行分析
web高可用：集群
nginx keepalive机制，在nginx集群间，down掉一个，通过心跳机制，另一backup 进行工作。另外对web层过来的进行流量分发，对server端的集群，down调，分发到ok的server上。Server 本身服务框架如dsf提供连接池、服务探测功能。
db 主主复制，主从同步。从集群保证。到家目前使用阿里云服务，主主复制，一从提供读服务。
2、高并发
方法论：加机器。还是从web--nginx--server--cache---db每个技术环节进行case分析。web层tomcat平均可支撑1k /s的请求。nginx5k/s.（智能DNS，根据用户请求ip直接路由到最近的省市服务器中）server层传统通过写大量存储过程，少量业务代码，利用cpu进行计算。
三、向牛人致敬
进入58一年的时间，跟沈老师来回有过好几次接触，我心中的牛人气质几乎完全符合。没架子，讲话平和，技术精湛且面广，重点是技术沟通总是深入简出，且均基于case说明问题，举一反三。从气质看人品，聊技术不禁每次接触后都感叹，受益颇深。简单list一下本次分享内容只是课程内容的小小一隅，重点我想分享或记录的是沈老师的思路。
1、系统是设计出来的，更是演进出来的
2、一定出现问题，才使用某种技术、某种解决方案来不断优化系统架构
3、高可用不外乎HA冗余、心跳检测、流量故障转移，每种方式的实现原理，一通百通举一反三
4、另外，public speech，尤其是专业性技术性强的分享，注意语速慢，娓娓道来。且使用项目实例case123说明问题。深入简出
后续还会进行系统解耦、秒杀等业务架构设计分享。持续更新。