常见性能优化策略的总结 _缓存服务器

文章插图
常见性能优化策略分类
代码
将代码放在首位的原因是它最容易被技术人员忽视。很多技术人员拿到一个性能优化需求后，一定会称之为缓存、异步、JVM等。其实第一步应该是分析相关代码，找到对应的瓶颈，然后再考虑具体的优化策略。有一些性能问题，完全是由于代码编写不合理造成的。问题可以直接修改代码解决，比如for循环太多，做很多不必要的条件判断，重复同样的逻辑很多次。
数据库
数据库调优一般分为以下三个部分：
SQL 调优
这个是最常用的，每个技术人员都应该掌握基本的SQL调优方法（包括方法、工具、辅助系统等）。这里以 MySQL 为例，最常见的方式是通过内置的慢查询日志或开源的慢查询系统定位具体有问题的 SQL，然后使用 , 等工具逐步调优，最终实现测试后的效果。在线的。这方面的详细内容请参考 MySQL 索引原理与慢查询优化。
架构级别调优
这类调优包括读写分离、多slave负载均衡、横向和纵向分库分表等。一般需要大改动，但频率不如SQL调优，而且一般要求DBA配合参与。那么这些事情什么时候需要做呢？我们可以通过内部监控和报警系统（例如）定期跟踪某些指标数据是否达到瓶颈。一旦达到瓶颈或警告值，就需要考虑这些事情。通常，DBA 也会定期监控这些指标值。
连接池调优
为了实现数据库连接的高效获取和数据库连接的限流，我们的应用通常采用连接池类型的方案，即每个应用节点对每个数据库管理一个连接池。随着业务访问量或数据量的增长，原有的连接池参数可能无法很好的满足需求。这时候就需要结合当前使用连接池的原理、具体的连接池监控数据和当前的业务量，在综合判断的基础上，通过多次反复调试得到最终的调优参数。
缓存
类别
本地缓存（/,, Guava Cache等），缓存服务（Redis/Tair/等）。
场景
什么时候适合使用缓存？考虑以下两种情况：
选择注意事项
设计要点
缓存什么时候更新？如何保证更新的可靠性和实时性？
更新缓存的策略需要具体问题具体分析。这里以store POI的缓存数据为例，说明缓存服务类型的缓存更新策略是什么。目前，大约有 100,000 个 POI 数据使用 Tair 作为缓存服务。具体更新策略有两种：
缓存是否会满，如果缓存满了怎么办？
对于一个缓存服务，理论上，随着缓存数据的增多，在容量有限的情况下，缓存一天肯定会满的。如何应对？
①服务缓存，选择合适的缓存驱逐算法，比如最常见的LRU 。
②对于当前设置的容量，设置一个合适的警告值，比如10G缓存。当缓存数据达到8G时，会发出告警，提前排查问题或扩容。
③给一些不需要长期保存的key，尝试设置过期时间。
缓存是否允许未命中？万一丢了怎么办？
根据业务场景，判断是否允许丢失。如果不允许，则需要具有持久化功能的缓存服务来支持，例如 Redis 或 Tair 。具体可以根据业务对丢失时间的容忍度，选择更具体的持久化策略，比如Redis的RDB或者AOF 。
缓存“崩溃”的问题
对于一些设置了过期时间的key，如果这些key在某些时间点可能会被超高并发访问，那就是非常“热”的数据。这时需要考虑另外一个问题：缓存“击穿”的问题。

文章插图
异步
场景
对于一些客户端请求，服务器可能需要为这些请求做一些辅助的事情。事实上，用户并不关心这些事情，或者用户不需要立即得到这些事情的处理结果。这种情况比较适合异步处理这些事情。