1 两台服务器
数据库和应用程序,分别在一台机器上。应用层序通过JDBC协议和数据库服务器通讯。
访问量增加,系统需要向前演进。(暂时不考虑,机器和软件层面的优化)
2 应用服务器负载告警,应用服务器走向集群
应用服务器压力变大时,根据对应用的检测结果,可以针对性优化。这里介绍把应用从单机变为集群。
2.1 遇到两个问题
- 应用服务器有两台,用户该访问哪台?
- session的问题
2.1.1 在应用服务器前,引负载均衡服务器
2.1.2 session会保存在单机上。
三个解决方案:
session sticky: 配置负载均衡服务器,同样的session标识,访问同一台服务器
缺点:负载均衡服务器,变成来了一个有状态的节点,保存着session和服务器的映射。
session replication:将session对象同步到每台服务器
缺点:用户量变大,服务器变多时,内存开销变大,网络开销变大
session数据集中存储:把session存在同一个地方
缺点:session数据服务器出问题,影响所有应用
cookie based:将session放在cookie
缺点:1.cookie长度受限制 2.session外部传输不安全 3. 消耗带宽 4.性能
3 读写分离
3.1 数据库作为读库
数据量和访问量在增加。对于大型网站,读多写少。
缺点:1.延迟
2.写到主库,读到备库,事务里都到主库
解决延迟:mysql5.5以后,采用semi-sync
3.2 搜索引擎
lucence
3.3 缓存
缓解数据库读压力
key-value
先访问缓存,再数据库
清楚冷门数据
缓存命中率
扩容,缩蓉
3.4 distributed storage 分布式存储系统
单机数据库,强的单机事务支持
分布式文件系统,分布式key-value系统,分布式数据库系统
4 数据库拆分
4.1 专库专用,数据垂直拆分
分布式事务;去掉事务。
4.2 水平拆分
垂直拆分,水平拆分, 读写分离
sql路由
主键重复
分页
5 应用面临的新挑战
5.1 某应用变大
存在user共享代码,不容易维护
直接访问存储层,希望进一步简化
6 走服务化路
web系统 业务服务 数据系统
远程调用 集中代码 web负责浏览器交互 业务业务逻辑和负责访问数据层
不通团队维护相应模块
消息中间件 message oriented middleware