性能优化最最关键

关于性能优化⼯具的使⽤，我主要是性能监控和性能调优的⼯具： a) Pinpoint或Skywalking。这是链路跟踪⼯具。⽬的在于了解整个交易链路 过程中性能到底在什么地⽅？这个主要链路问题的定位，因为整个链路往往跨了 N个系统（或服务），那么到底是哪个服务最慢？是应⽤慢还是数据库慢？是 Redis慢？还是MQ慢？还是⽹络慢？通过Pinpoint或Skywalking是可以⽐较清楚 的看到的。同时这两个⼯具是开源的，可以直接使⽤。 b) jProfiler。这个⼯具是单个应⽤或服务的Debug⼯具。他会将当个Server 的整个执⾏代码级的执⾏轨迹和时间罗列出来，包括线程的锁的信息、SQL执⾏ 的信息等等。 优化策略： 上述两个⼯具旨在确定性能问题的具体位置，优化策略是需要根据确定的问 题来进⾏优化。但总体上的⼤策略就是，要减少数据库的 *** 作，让数据库的SQL 尽可能的少，尽可能的简单，因为数据库是很难做⽔平扩展的。具体数据库的优 化策略： 1. 使⽤缓存代替SQL查询（实际本地缓存就⾏，并不⼀定⾮要使⽤ Redis）。 2. 每个SQL都需要⾛索引，决不能出现虽然sql很快但没有索引的情况 （特别是费率表，我们很不愿意给费率表、现价表建索引）。 3. SQL硬解析改绑定变量。这个在农银和PICCH都取得了巨⼤性能提升 （数据库层级），会降低⾮常多DB的CPU消耗。 4. 读写分离。把查询、报表挪到只读数据库中查询。 5. 减少查询次数。检查程序逻辑，看看有没有反复查询的SQL，最好⼀ 段逻辑⼀次性把必要的数据全部取出，就不在反复读取。 应⽤优化的策略，实际主要是要看jProfiler的监控报告，但我能想到如下： 1. Log是性能的很⼤的瓶颈，如果吧info改成error，性能能提升30% 多。因此需要检查是否必要的⽇志输出，是否有多⾏输出可以合并为⼀⾏输 出（有的开发⼈员习惯不好，形式喜欢⼀⾏输出⼀个参数，然后还写⼀些星 号花边觉得很好看，但实际上都是⽆效的输出，最好⼀⾏解决所有需要输出 的参数。我看很多阿⾥的⽇志，⼀个交易，就是⼀个⼤json⽇志，只有1⾏。 ⽽我们⼀个交易，估计的有⼏百上千⾏） 2. ⽣成号。⽣成号应该是⾮常⾮常⼤的瓶颈，主要是有数据库锁的问 题。这个问题⼀般来说需要分两部分看，⼀⽅⾯，⽣成号应该加应⽤缓存， 每次缓存⼀部分，我这边⾃⼰系统优化的策略是按线程缓存，主要是为了避 免线程在get的缓存的时候有Thread Lock的问题。另⼀⽅⾯，可能有些内部 ⽣成号码id，应采⽤SnowFlake ID算法⽤应⽤直接⽣成号，⽽不要在数据库 记录号码，记录意义实际不⼤。 3. Thead Lock. 这个问题实际是我们会使⽤多线程、或者其他线程 *** 作，会有synchronized的 *** 作，这个是需要⼤家在全系统中搜索，从逻辑上 来讲，整个在线交易链路上，是决不能有synchronized过程的。否则并发度 是达不到的。变通的解决⽅法，就是需要借助Theadlocal 或 ⾃⼰写线程层 级的缓存来进⾏处理。举例，有些个别的XML引擎，是线程不安全的，所以 需要同步处理，那么就每个线程创建⼀个XML Factory，那么每个线程⽤⾃ ⼰的xml解析引擎。 4. 避免频繁的重复逻辑。这部分主要是我们的代码是很⻓时间写的。遗 留了很多重复的逻辑。反复 *** 作。反复查询。导致效率低下。这部分是是需 要持续代码重构来解决的