个人Java总结

*一次Java系统升级总结

**
随着用户数量的增加，加上营销系统常常出现秒杀，抢券等营销活动，对系统中的关键业务瞬时处理要求变得越来越高。在平时开发生活中，为了加快开发速度大多数开发人员常常只关注功能实现，但正是这样，系统在高并发的情况下，系统的高可用性常常十分差。为此总结一下我在工作中对系统优化的一些小的经验和理解，希望大佬勿喷。

*解决思路

1.物理层面
2.架构层面
3.软件开发层面
由于本人刚刚从事软件开发4个月，在此对物理层面和架构层面简单说一说个人体会，本文更多的是对软件开发层面的理解。
1.物理层面
增加机器和带宽永远是解决最直接也是最有用的办法，只有在达到硬件层面无法解决，就考虑软件层面优化，这样符合计算机的软硬件发展，只有硬件层面达到瓶颈，就想着优化软件更加合理调度硬件资源，达到优化目的。同时对jvm的合理设置也体现了对硬件资源的合理使用，可以达到优化目的（jvm调优应该放在最后）。
2.架构层面
系统架构：面对高并发场景，个人认为分布式微服务相对单体服务架构有着绝对优势，不单单是服务易于伸缩扩展提高高性能（即根据不同服务压力动态调整每一个服务所需要的机器数和硬件资源），更重要的是，单一服务组件的“死亡”不会直接影响整个复杂综合系统的“死亡”，就如同人体每日红细胞的死亡对人体正常活动影响很小，而单体架构单一服务的“死亡”就直接影响了这个复杂的综合系统。同样，分布式的微服务，提供了各种负载均衡和可靠的服务熔断机制，大大提升了服务的高可用。
缓存架构：软件响应时间最耗时的部分就是对资源的io操作上面，静态资源的加载，数据库数据的读取等，所以缓存设置很多都是为了减少对文件系统的io操作，但是缓存存在代价，就是数据的实时性和可靠性，缓存常常是利用数据实时性换取性能，这为后续的缓存不一致问题出现埋下伏笔，例如代码中自定义map缓存与redis缓存不一致，redis与数据库缓存不一致等等问题。所以缓存不仅要用，更要合理使用。
3.软件开发层面
数据库方面：数据库表设计到sql语句都是可以优化的地方，当然表设计一般不会修改，因为涉及到大量具体业务，改动代价太大。更多的是考虑数据查询的时候是否走了索引，以及在构建索引字段的可维护性，索引是否失效等等问题，同样在联表查询时候尽量利用小表驱动大表，数据量太大之后分库分表也需要考虑。
编码方面：编码方面面对高并发，本人目前解决方法只有三招：多线程，redis，mq；多线程的使用很多时候并不是线程越多越好，线程的开启，调度，销毁都是需要时间的，常常是因为一段代码的执行结果并不是主线程立即所需的，最理想的状态就是主线程刚好需要结果或者在主线程需要之前完成这段代码执行，因为这样才能真正做到不阻塞主线程情况下，利用子线程减短代码执行时间。redis就不用说了，其主要目的就是完成缓存工作，减轻数据库瞬时压力，但要注意的是，高并发下的redis分布式锁问题，以及在部分问题上是否可以利用lua脚本代替分布式锁（例如lua脚本解决商品库存超卖等等），毕竟锁操作会存在阻塞问题。最后，减轻代码执行也是重要一环，这个时候就需要mq的异步和解耦了，在最小化影响主流程的情况下，将部分代码执行交给mq的消费者，最终达到削峰的目的，但需要注意的是合理设置消费者数量，避免出现数据量大，单一消费者消费慢导致mq队列阻塞。