前言
昨晚救火到两三点, 早上七点多醒来, 朦胧中醒来发现电脑还开着, 赶紧爬起来看昨晚执行的 SQL 命令结果. 由于昨晚升级了阿里云的 RDS, 等了将近两个小时 还在 升降级中, 早上阿里云那边回复升级过程中出现异常, 正在加紧处理... 有点蛋疼
项目介绍
这个项目主要分为 web,Web-Manager,Web-API,App(Android,iOS) .
开发语言主要是 ASP.NET
数据库 MySQL
架构采用了 ASP.NET +EF+ORM Unity 依赖注入 采用了 DDD 的部分实践
ORM 使用的是 AutoMapper
使用了 Redis 缓存
Log4net 记录文件日志, 刚开始使用 MongoDB 记录日志, 用了一段时候后取消了.
Web 端使用了 AngularJS
API 层通过 JSON 数据与 App 进行交互, 用户状态通过 access_token 进行传递
数据库层目前是基于仓储 (Repositor) 模式实现的
刚开始项目急于上线多数采用 Linq +lambda 的查询方式, 在实践过程中发现变态的业务调整和快速的请求响应, 将其复杂的查询改成了原生 SQL, 通过 Context.DataBase.SqlQuery 执行
其他的技术就不一一介绍了
目前访问量较大的是 App 端, 最大并发 1300+
主要是 API 的压力比较大, 日均 100W+ 请求, API 目前 部署在 Windwos server 2012 上, 接口在 50 个以上
数据库使用的是阿里云的单机 MySQL RDS 5.6 版本, 10 盒 12G, 连接数 2000,iops 6000
目前 单表最大是 8000W + 数据. 物理文件 300G,APIlog 日均 100W+,API 与业务系统完全独立, 除了 DBLog 日志还有 Log4g.NET 生成的文件日志.
目前采用的是阿里云的负载, 一主一从 购买的阿里云负载 两台应用均为 8 盒 16G ,10M 带宽 , 资源文件上了 CDN.
主的上面部署了 Web 端和 Web 管理后台, 从的上面只有 API.
数据库遇瓶颈
最近用户量突破 10 + 以上, 最大并发 1300+ 从前天晚上开始数据库 CPU 居高不下, 一时达到 100% 临界点, 导致很多 SQL 命令执行发生错误, 链接拒绝. 阿里云的报警短信也随之而来, 随即我停掉了 IIS 应用, 因为不停止应用 MySQL 数据库很难复苏, 大概过了 5 分钟之后数据库恢复正常, 然后再开启 IIS 应用. 蛋疼的是阿里云的负载健康检查也提示异常, 但有点不解的是健康状态显示异常, 请求仍然在继续分发, 很是不解. 立马我将 IIS 应用程序池资源回收, 停止然后再重启, 这里给个提示 重启 IIS 应用程序池的时候最好先停止掉 IIS 应用, 然后再重启 IIS 应用程序池, 不然访问量大的情况下很难起起来. 过了几分钟之后负载上的健康检查显示正常.
上阿里云后来看了下各个监控指标, 显示流量从前一个小时开始 突然猛增, 我以为是有攻击, 但跟踪了几个连接发现是正常请求, 但 360 的防御助手显示确实有几个攻击, 但那几个请求根本不足以拉跨数据库, 大概也就几十个请求, 几个简单的 XSS 攻击 这里贴下: 攻击的数量不是太多, 但主要攻击的内容和参数就这个几种类型
- url/'%22/%3E%3C/script%3E%3Cscript%3Ealert()%3C/script%3E
- url/'%22+onmouseover=alert()+d='%22
url/matrix_callback.PHP
url/index.PHP?option=com_fields&view=fields&layout=modal&list%5Bfullordering%5D=updatexml(0x3a,concat(1,md5(233)),1)
后来发现是数据库遇到危机了, CPU 几度达到了 100%, 活跃连接数和非活跃连接数都比平时都要高很多. 目前数据库中有一张最大的表超 8000W 条数据, 超 300W 以上的也有十几张, 是查询拖垮了数据库, 平时开发的时候我们都是要求查询类的 SQL 要求 0.03 秒之内完成. 但涉及到这几张大表的查询我们设定到 0.5 秒之内返回. 今天肯定是查过 0.5 秒了,
我查了下阿里云控制台的慢 SQL 日志, 眼下系统运行还稍微正常, 就拿那些慢 SQL 一个一个的优化, 不能立马发版, 也就是不能改写 SQL 代码, 只能从索引上进行优化了. 就这样把慢 SQL 逐一过了一遍, 大约有 20 多个 超 2 秒执行的, 最慢的达到了 10 秒, 最大的解析行数达到了 10W 行以上, 哎 应该是下面的兄弟写 sql 不严谨, 否则不会出现解析行数超 10W + 的, 但兄弟挖的坑 我哭着也要去填. 就这样用 explain 调整索引的方式逐一过了一遍, 之前通过表空间已经做过一次优化了.
到昨晚又到了高并发的时候, 数据库又报警了, 还好只是报警没有给我 crash 掉. 与客户那边沟通下来, 决定进行数据库扩容. 现在扩容到了 16 盒 64G 连接数 14000 iops16000.
增加了一个应用几点, 现在是一主两从
应该能撑一段时间了
接下来需要着手上读写分离, 针对比较大的表进行拆分, 代码和数据库继续优化. 尽量做到最优.
再下来着手上分布式 因为架构的演变是根据市场营销情况而定, 不能走太前更不能走到市场的后面
周末比较累 写的比较简短, 有时间再续
来源: http://www.bubuko.com/infodetail-3330707.html