ASP源码.NET源码PHP源码JSP源码JAVA源码DELPHI源码PB源码VC源码VB源码Android源码
当前位置:首页 >> 网络编程 >> Java教程 >> 性能优化实战-2

性能优化实战-2(1/3)

来源:网络整理     时间:2018-10-04     关键词:

本篇文章主要介绍了" 性能优化实战-2",主要涉及到方面的内容,对于Java教程感兴趣的同学可以参考一下: 我们在做架构设计的时候,会提到几个关键词:高性能、高可用、可扩展、安全性、伸缩性、低成本等等。对于用户量不大、并发量不高的系统,我们没必要去追求高性能,甚至连架...

我们在做架构设计的时候,会提到几个关键词:高性能、高可用、可扩展、安全性、伸缩性、低成本等等。对于用户量不大、并发量不高的系统,我们没必要去追求高性能,甚至连架构设计都可以免了。

那么什么样的系统需要做性能优化呢?当你发现系统响应越来越慢,慢到已经影响到用户体验的时候;

网站性能优化的手段:

1、 web前端优化;

减少http请求;

使用浏览器缓存;

静态资源压缩;

减少cookie传输;

CDN加速;

反向代理;

2、 应用服务性能优化;

分布式缓存,通过添加缓存来提高应用层的响应效率;

消息异步化:线程、队列等等;

集群服务;

代码优化:事务粒度调整、算法优化等;

3、 数据库层优化;

表结构优化、SQL优化,索引等等;

我们先看看交易所币币交易的业务流程:

拿委托来说,原有的逻辑如下:

用户登录后发起委托申请;

后台进行用户状态、资金密码可用、货币状态等校验;

校验通过后将委托单入库并冻结用户可用余额;

将委托单发送给撮合队列进行撮合;

通过梳理委托业务流程,我们发现委托的性能瓶颈主要在数据库层面,包括第二步的校验和第三步的数据持久化。而第四步的入队列操作比较简单,简单来说就只是一个队列消息发送,原则上并不会产生性能瓶颈。

第二步的校验如何进行优化?校验是必须的,不校验是不可能的,这辈子都不可能。那那那怎么办?

校验数据读缓存。

首先,用户登录时已经将用户信息放入SESSION,用户状态校验直接拿SESSION信息进行比对就可以了。考虑到用户登录后用户状态信息可能会调整,那么在调整后需要将用户信息及时更新到SESSION。另外,测试在做登录压测的时候,发现登录接口的吞吐量一直上不去,查表发现用户表数据量比较大,登录是通过手机号码进行登录的,所以我们对用户表的手机号码列加了唯一索引。

资金密码可用的校验需要查用户密码策略表进行交易。用户密码策略基本属于较少变更的信息,可以将密码策略加入常驻缓存(一直放在缓存)。另外,为提高用户密码策略表的查询效率,对密码策略表创建用户ID和货币ID联合索引。

我们直接将货币信息、货币对信息加入常驻缓存,后台货币有调整时及时更新至缓存,所以货币状态的校验也改成了缓存读取数据并做校验。

第三步的数据持久化怎么办?第三步操作还涉及到用户可用余额的校验,用户可用余额校验必须要在用户发起委托申请时来做,看来这一步不能省。那还有优化的空间么?

我们借鉴了互金资产交易系统中防超投的处理方案,将用户可用余额添加到缓存。有人会问,如果数据库数据和缓存数据不一致怎么办?解决方案是缓存操作和数据库操作都保持同步,如果不能同步更新,那至少也需要保证缓存数据和数据库数据的最终一致。

具体到委托申请这块,我们先冻结缓存中的用户可用余额,然后将委托单加入撮合队列,在进行撮合的时候再将冻结金额持久化到数据库。

简单总结一下委托下单的优化点:

数据校验读缓存,以减少频繁查库带来的数据库压力;

数据持久化先入队列,延迟写入数据库,以降低数据库的压力;

为数据库表添加必要的索引,提高查询效率;

接下来,我们看下挂单撮合的业务流程:

冻结可用金额持久化和委托单持久化;

从对方队列队首取出委托单进行撮合;

撮合成功后将撮合结果添加到撮合持久化队列;

我们以挂买委托单为例来了解一下撮合的操作流程:

1、在挂买委托单过来之后,从卖队列(所有未撮合完成的卖委托单组成的集合)中弹出队首的卖委托单。

2、如果无卖委托单或者卖委托单的价格高于买委托单的价格,则不进行撮合,将买委托单加入买队列集合。如果卖委托不为空,将卖委托重新加入卖队列。

相关图片

相关文章