虽然我们部门不是属于电商这类高并发要求非常高的业务部门。但是，我们也面临这在一些特殊的节日的或者有热门活动的时候，大量的用户购买同一游戏道具或者大量用户同时关注某个活动所带来的流量激增以及骤降问题，说到底也是一种高并发问题！举个简单的例子，在一个活动上线后，我们碰到首要的难题其实并不是订单购买这个环节的问题！而是游戏道具的查询服务承受不了大流量的问题。原因很简单，对用户来说光看不买是没有什么成本的！造成的后果就是看着看着把道具给看没了.....
那么究竟该怎么优化系统的整体性能，提高用户的使用体验呢？我认为可以从几个方面进行优化：
性能优化
所谓性能就是要保证系统的高性能，让用户的请求能够及时得到处理及响应！主要的优化点在于后端处理这端！可以有如下的方案：
-
横向扩展
也就是物理扩展，也就是将一个业务部署到多台机器，让经过业务的流量能够分摊到多个点达到降低整体压力的效果！
-
请求优化
-
请求数量减少
网络传输也是影响响应时间的重要一环，我们可以尽量将一些可以合并的接口合并到一个接口中，避免进行多次调用！这和微服务的模块化是有一点矛盾的，但其实也不矛盾！就不重点讨论了！另外，也可以将多个资源放在同一个资源中一起返回从而避免多次获取带来的消耗。
-
交互数据减少
类似我们获取某一个组件数据的时候往往带了大量的其他组件相关的数据，而后续又不会操作该组件。造成一个请求中携带了大量不必要的数据！类似的这些场景下，我们就需要利用一些缓存技术来缓存一些前端数据，请求中不要携带不必要的参数等。
-
动静分离
将静态资源请求和动态资源分开，可以利用nginx等工具进行！对于静态资源也可以利用cdn进行获取！
-
-
系统依赖优化
定期进行系统定级，使用一些异步组件对系统的一些附属功能进行异步处理，不要拉低系统主要业务的处理能力！比如利用MQ的异步特征处理系统附属的一些功能，或者是开额外的线程完成非主要业务！
-
单点优化
-
首当其冲的是代码优化，很多性能问题其实并不是天灾，而是人祸，比如循环次数、无谓的条件判断、逻辑重复多次等等问题！所以代码优化也非常重要！
-
数据库层面优化
-
SQL调优
我们可以利用SQL调优的一些调优方法、调优工具来检测问题所在，然后进行针对性优化。以MySQL为例，我们可以利用MySQL自带的慢查询日志或者开源的慢查询系统定位到问题SQL，然后使用explain、profile等工具进行检查，调优！
具体操作可以有，数据库字段设计检查，包括字段长度设计、数据类型设计、规范约束设计，值得一提的是外键这个东西能不用就不用；索引设计检查，包括主键的设计，索引的个数，索引失效情况的设计避免，联合索引设计，索引覆盖的优化等；SQL查询过程审计拆分优化，也就是SQL编写，比如，多表查询不要超过三个表，多表连接查询的情况可以分多次，每次得出关联值即可。尽量不要使用子查询。SQL查询要避免索引失效等；SQL查询执行情况分析，使用explain检查SQL的执行情况，测试过程中就尽可能的发现问题所在，及时进行修复，问题不应该出现在生产环境。
-
数据库架构调优
在这个数据为王的时代，单库的情况几乎是不存在了！所以数据库架构调优也就指的是多库优化！通用的一些方案：
读写分离将db的读写压力分开，让其互不干扰，然后使用多从库的负载均衡减少大量的读需求在从节点的压力！然后对于主数据库的写压力，我们可以使用分库分表技术，将同类型数据分到不同表的，将不同的业务分到不同的节点！
-
数据库连接优化
由于数据库本身的并发性并不是很好，同时操作还需要获取锁。当大量的请求都需要操作数据库的时候，就有可能将数据打垮。这时候我们就需要控制数据库的访问量。可以从两个方面，一个是数据库连接池的优化，主要体现为数据库连接池参数的动态调整。一个是通过分布式锁等方式让请求排队进入。
-
-
缓存
缓存主要的应用场景在于短时间内多次获取相同的资源且资源长时间不更新，另外就是类似一些热点数据的查询场景！缓存的设计需要考虑到缓存实时性，如何更新缓存，缓存淘汰策略，缓存高可用性问题，以及缓存击穿，穿透，雪崩等问题！
-
内存缓存（map等数据结构）
优点是内存操作比较快，缺点是缓存限于本地环境而且不能持久化，会随着机器的关闭而丢失！
-
磁盘缓存（文件缓存）
优点是能够持久化，宕机不会丢失，但是读写速度是慢，同样限于本地环境！
-
集中缓存（Redis等三方存储）
优点是能够持久化，并且可以多节点分布，适用于分布式存储场景，速度介于内存和文件缓存中间！
-
-
JVM调优
这块个人仅仅知道对各分代分区区域内存大小进行调节，以及gc时间进行调节，没有实操过。暂且提一提，后续再补充！
-
