一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？请列举描述。
应用服务器：Spring + Tomcat + Mybatis
此外，通过池化技术提高数据库的 TPS 和 QPS
应用服务器：Spring + Tomcat + Mybatis + c3p0 数据库：Mysql
瓶颈：服务经常宕机，可用性比较差。
基于高可用的角度，
使用 keepalived 实现应用服务器和数据库做 HA
瓶颈：应用服务器
反向代理：nginx 无状态的应用服务：N 个 数据库：HA
要点：
一、对于有状态的服务涉及 Session 的处理。
反向代理支持 session 保持，但是应用服务器的增加和删除，导致 session 失效应用服务器之间进行 session 同步部署 HA 或集群模式的 session 服务器session 存在cookie中，右浏览器来告诉应用服务器 session，以此实现了session和应用服务器的解耦二、动静结合 1、静态资源是用反向代理 2、静态资源使用 CDN 3、静态资源使用浏览器缓存
瓶颈：数据库，读写比例失衡，超出数据库处理能力
绝大多数应用是读多写少，因此，进行读写分离。
反向代理：nginx 无状态的应用服务：N 个 数据库：HA + 多个从节点（3-5）
要点：
一、判断主从延迟 1、 seconds_behind_master 2、点位法 3、 GTID 法
二、主从数据之间的延迟 1、强制走主库法：对一致性低的，可以直接读从节点；一致性高的，走主库读。 2、判断主库延迟法：对操作根据一致性的要求高度应用，通过判断主库延迟来决定读从库还是读主库。 3、半同步法 4、等主库点位法 5、等 GTID 法 6、写缓存法
三、访问数据模式 1、三方依赖：ShardingJDBC、TDDL 2、代理层：MyCat、DBProxy
瓶颈：数据量很超过单机存储能力。
反向代理：nginx 无状态的应用服务：N 个 数据库：HA + 多个从节点（3-5）+ 分库 + 分表
要点： 1、全局唯一 ID：ID 发号器 2、分库分表的逻辑：基于范围、基于 hash 3、引入NoSQL：比如引入 ES 满足特定场景的读性能，HBase 满足更大数据量的处理
反向代理：nginx 无状态的应用服务：N 个 缓存：redis、memcached 数据库：HA + 多个从节点（3-5）+ 分库 + 分表
要点 一、缓存分离 本地缓存：guava、caffine、ehcache 分布式缓存：redis、memcached
二、缓存更新套路 1、cache Aside 2、write through、read through 3、write back
三、缓存引入问题 1、热点问题 2、缓存穿透 3、缓存击穿 4、缓存雪崩
反向代理：nginx 无状态的应用服务：根据DDD 思想对服务精拆分 缓存：redis、memcached 数据库：HA + 多个从节点（3-5）+ 分库 + 分表
要点 1、服务治理：服务发现、配置中心、注册中心、客户端负载均衡、熔断、限流、链路跟踪等等服务治理手段。 2、DevOp、服务网格应对应用爆炸 3、引入消息中间件解耦。
反向代理：nginx 无状态的应用服务：根据DDD 思想对服务精拆分 缓存：redis、memcached 数据库：HA + 多个从节点（3-5）+ 分库 + 分表 数据分析：大数据平台、AI 平台
要点： 1、建立大数据技术对业务进行分析，找到业务数据的价值 2、引入机器学习、AI 技术赋能业务 3、AIops 简化运维 4、Cloud Native 5、业务中台、数据中台、AI 中台
参考 https://segmentfault.com/a/1190000018626163 细节还不够 https://blog.csdn.net/jayxujia123/article/details/106731775
根据当周学习情况，完成一篇学习总结
本周最大的收获大概就是将进入阿里受挫的那段讲解。
当前遇到的瓶颈期是自己成长的最快时期，突破了海阔天空。发现问题比解决问题更加重要。想想google、facebook、阿里、京东、美团、头条、拼多多的崛起无不是看问题的角度不一样。发现问题，比解决问题更加重要。同样的事情，高手更重要的是对问题的理解不一样。今天看了人人网的发展历程，不得不感慨，不是拿一副好牌就能赢。