问答：一个数据库连接数量过多怎么办？连接池的缺点？
如果每一个app都有连接池，最小连接为8，最大为10，随机访问，每一个app的连接并不能保证访问是平均的，有些app很多连接浪费。解决办法就是在应用和数据库之间加一层：1.100app +3台中间数据库连接服务（代理模式）+数据库，2.连接复用。提升连接的利用率。
讨论方案1到底是重还是轻。
一个大业务或者系统会造成冲突-->拆成一个一个的小模块，由单独团队负责,减少冲突和拆解业务，这个时候如果模块能够单独开发和部署（能轻量开发，减少冲突，连接减少）。高内聚，低耦合。这个时候就要做服务化。
服务化的发展：怎样知道服务，有哪些服务？
DNS的原理可以解决这个问题但是不能很快感知IP地址的变化（DNS定时主动拉取）。
软负载：nameserver 后面服务机器和他保持长连接，很快感知后面服务的IP是否可用
这个时候要解决nameserver单点的问题（解决方法：1.nameserver热备，2把服务IP缓存到webapp端）
nameserver什么时候会起作用？服务的上线和服务的下线才会用到。
nameserver集群变大会使集群的同步状态变的很难维护（服务不可用的时候，IP下架的时候）。
nameserver使用缓存，一个点写数据，多个点读数据 （主备节点，对等集群分担读的压力）诞生了configserver(实现方式是zk。发布订阅模式都可以实现)
服务化具体的方案：使用configserver的hsf、dubbo，这些远程服务调用RPC都是基于接口和序列化
consumer和provider。创新性的东西配置服务--远程调用配置成本地调用。
分布式数据库分层：tddl针对mysql实现切分和扩展，分库分表(sharding)。分布式jion和分布式事务（可以再开一个博客）
高级事务支付宝的账务事务是用的异步事务（事务的本质就是锁）。
次异步的事务使用单机保证，写都在一台机器上。
请求的分散治理：负载均衡 ，所有系统都可以扩展
内容分发网络：cdn 是什么，对cdn有什么改进？软硬件结合（低功率，低损耗）硬件的东西
搜索引擎：倒排索引+缓存系统 ，倒排索引是什么？索引词典+倒排列表 可以看开源软件
压缩，个性化搜索（推荐），快速试错，理解语义拟人化。
数据分析：用户，交易订单等等数据放到一起，一起分析
hadoop 1.0----2.0 storm ----spark
存储NOSQL：列存储可以使用较高效率的压缩算法。更新的时候比较差劲了（怎样绕开呢，删除的时候不是真的删除，解压缩是要耗时耗资源的）。
最后的架构图
一个单机的web服务的优化：
http服务器（nginx，nginx的高效使用openresty），jvm最大的问题就是gc，如果内存很大且不能回收，比如类目树。协程更轻量级的线程，一个线程内维护自己多个任务。线程切换很耗时好资源，线程A挂起保存线程状态，线B读取在运行。
JVM优化：gc优化,协程，gc算法，即时编译优化，定制功能增强。
好啦其实后面还有30分钟但是我觉得还是太粗糙了，下一篇博客，架构模式与实践漫谈的总结报告。
408
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
