苏州网站设计公司官网,wordpress预缓存,app定制开发公司选择,长沙网页建站本文是我从业多年开发生涯中针对线上业务的处理经验总结而来#xff0c;这些业务或多或少相信大家都遇到过#xff0c;因此在这里分享给大家#xff0c;大家也可以看看是不是遇到过类似场景。本文大纲如下#xff0c; 后台上传文件 线上后台项目有一个消息推送的功能#…本文是我从业多年开发生涯中针对线上业务的处理经验总结而来这些业务或多或少相信大家都遇到过因此在这里分享给大家大家也可以看看是不是遇到过类似场景。本文大纲如下 后台上传文件 线上后台项目有一个消息推送的功能运营新建一条通知消息时需要一起上传一列包含用户 id 的文件来给文件中包含的指定用户推送系统消息。 如上功能描述看着很简单但是实际上处理上传文件这一步是由讲究的假如说后台上传文件太大导致内存溢出又或者读取文件太慢等其实都是一些隐性的问题。 对于技术侧想要做好这个功能保证大用户量比如达到百万级别下上传文件、发送消息功能都正常其实是需要仔细思考的我这里给出我的优化思路 上传文件类型选择 通常情况下大部分用户都会使用 Excel 文件作为后台上传文件类型但是相比 Excel 文件还有一种更加推荐的文件格式那就是 CSV 文件。 CSV 是一种纯文本格式数据以文本形式存储每行数据以逗号分隔没有任何格式化。 因此 CSV 适用于简单、易读、导入和导出的场景而且由于 CSV 文件只包含纯文本因此文件大小通常比 Excel 文件小得多。 但是 CSV 文件针对复杂电子表格操作的支持就没 Excel 功能那么强大了不过在这个只有一列的文件上传业务里够用了。 假如说上传文件中包含 100 万用户 id那么这里使用 CSV 文件上传就有明显优势占用内存更少处理上传文件也更快。 消息推送状态保存 由于大批量数据插入是一个耗时操作可能几秒也可能几分钟所以需要保存批量插入是否成功的状态在后台中还需要显现出这条消息推送状态是成功还是失败方便运营人员回溯消息推送状态。 批量写入 针对这里上传大文件时的批量写入场景这里提几个点大家注意一下就行 rewriteBatchedStatementstrue MySQL 的 JDBC 连接的 url 中要加 rewriteBatchedStatements 参数并保证 5.1.13 以上版本的驱动才能实现高性能的批量插入。 MySQL JDBC 驱动在默认情况下会无视 executeBatch()语句把我们期望批量执行的一组 sql 语句拆散一条一条地发给 MySQL 数据库批量插入实际上是单条插入直接造成较低的性能。只有把 rewriteBatchedStatements 参数置为 true 驱动才会帮你批量执行 SQL。另外这个选项对 INSERT/UPDATE/DELETE 都有效。 是否启用事物功能 批量写入场景里要不要启用事物其实很多人都有自己的看法这里我给出启用于不启用的利弊 启用事务好处在于如批量插入过程中异常情况可以保证原子性但是性能比不开事务低在特大数据量下会明显低一个档次 不启用事务好处就是写入性能高特大数据量写入性能提升明显但是无法保证原子性 在本文提到的大文件上传批量写入的场景下要是追求极致性能我推荐是不启用事务的。 假如在批量写入过程中发生网络波动或者数据库宕机我们其实只需要重新新建一条通知消息然后重新上传包含用户 id 的文件即可。 因为上一条通知消息因为批量插入步骤没有全部完成所以推送状态是失败。后续等开发人员处理一下脏数据即可。 大事务 Transactional 是 Spring 框架提供得事务注解相信这是许多人都知道的但是在一些高性能场景下是不建议使用的推荐通过编程式事务来手动控制事务提交或者回滚减少事务影响范围因而提升性能。 使用事务注解 如下是一段订单超时未支付回滚业务数据得代码采用 Transactional 事务注解 Transactional(rollbackFor Exception.class)
public void doUnPaidTask(Long orderId) {// 1. 查询订单是否存在Order order orderService.getById(orderId);// 2. 更新订单为已取消状态order.setOrderStatus((byte) OrderStatusEnum.ORDER_CLOSED_BY_EXPIRED.getOrderStatus());orderService.updateById(order);...// 3. 订单商品数量增加LambdaQueryWrapperOrderItem queryWrapper Wrappers.lambdaQuery();queryWrapper.eq(OrderItem::getOrderId orderId);ListOrderItem orderItems orderItemService.list(queryWrapper);for (OrderItem orderItem : orderItems) {Long goodsId orderItem.getGoodsId();Integer goodsCount orderItem.getGoodsCount();if (!goodsDao.addStock(goodsId goodsCount)) {throw new BusinessException(秒杀商品货品库存增加失败);}}// 4. 返还用户优惠券couponService.releaseCoupon(orderId);log.info(---------------订单orderId:{}未支付超时取消成功 orderId);
} 可以看到上面订单回滚的代码逻辑有四个步骤如下 查询订单是否存在 更新订单为已取消状态 订单商品数量增加 返还用户优惠券 这里面有个问题订单回滚方法里面其实只有 2、3、4 步骤是需要在一个事物里执行的第 1 步其实可以放在事物外面来执行以此缩小事物范围。 使用编程式事务 使用编程式事务对其优化后代码如下 Resource
private PlatformTransactionManager platformTransactionManager;
Resource
private TransactionDefinition transactionDefinition;public void doUnPaidTask(Long orderId) {// 启用编程式事务// 1. 在开启事务钱查询订单是否存在Order order orderService.getById(orderId);...// 2. 开启事务TransactionStatus transaction platformTransactionManager.getTransaction(transactionDefinition);try {// 3. 设置订单为已取消状态order.setOrderStatus((byte) OrderStatusEnum.ORDER_CLOSED_BY_EXPIRED.getOrderStatus());orderService.updateById(order);...// 4. 商品货品数量增加LambdaQueryWrapperOrderItem queryWrapper Wrappers.lambdaQuery();queryWrapper.eq(OrderItem::getOrderId orderId);ListOrderItem orderItems orderItemService.list(queryWrapper);for (OrderItem orderItem : orderItems) {Long goodsId orderItem.getGoodsId();Integer goodsCount orderItem.getGoodsCount();if (!goodsDao.addStock(goodsId goodsCount)) {throw new BusinessException(秒杀商品货品库存增加失败);}}// 5. 返还优惠券couponService.releaseCoupon(orderId);// 6. 所有更新操作完成后提交事务platformTransactionManager.commit(transaction);log.info(---------------订单orderId:{}未支付超时取消成功 orderId);} catch (Exception e) {log.info(---------------订单orderId:{}未支付超时取消失败 orderId e);// 7. 发生异常回滚事务platformTransactionManager.rollback(transaction);}
} 可以看到采用编程式事务后我们将查询逻辑排除在事务之外这样也就减小了事物影响范围。 在极高性能优先的场景下我们甚至可以考虑不使用事务使用本地消息表 消息队列来实现最终一致性就行 。 海量日志采集 公司线上有一个项目的客户端采用 tcp 协议与后端的一个日志采集服务建立连接用来上报客户端日志数据。 在业务高峰期下会有同时成千上万个客户端建立连接实时上报日志数据。 在上面的高峰期场景下日志采集服务会有不小的压力如果程序代码逻辑处理稍有不当就会造成服务卡顿、CPU 占用过高、内存溢出等问题。 为了解决上面的大量连接实施上报数据的场景日志采集服务决定使用 Netty 框架进行开发。 这里直接给出日志采集程序使用 Netty 后的一些优化点 采集日志异步化 针对客户端连接上报日志的采集流程异步化处理有三个方案给大家介绍一下 普通版采用阻塞队列 ArrayBlockingQueue 得生产者消费者模式对上报的日志数据进行异步批量处理在此场景下通过生产者将数据缓存到内存队列中然后再消费者中批量获取内存队列的日志数据保存入库好处是简单易用坏处是有内存溢出风险。 进阶版采用 Disruptor 队列也是一个基于内存的高性能生产者消费者队列消费速度对比 ArrayBlockingQueue 有一个数量级以上得性能提升附简介说明https://www.jianshu.com/p/bad7b4b44e48。 终极版也是公司日志采集程序最后采用的方案。采用 kfaka 消息队列中间件先持久日志上报数据然后慢慢消费。虽然引入第三方依赖会增加系统复杂度但是 kfaka 在大数据场景表现实在是太优秀了这一点也是值得。 采集日志压缩 对上报后的日志如果要再发送给其他服务是需要进行压缩后再处理这一步是为了避免消耗过多网络带宽。 在 Java 里通常是指序列化方式Jdk 自带得序列化方式对比 Protobuf、fst、Hession 等在序列化速度和大小的表现上都没有优势甚至可以用垃圾形容。 Java 常用的序列化框架有下面这些 JDK 自带的序列化性能较差占用空间大无法跨语言好处是简单易用通用性强。 JSON常用的 JSON 库有 Jackson、Gson、Fastjson 等。性能较好占用空间少跨语言支持广泛但是无法序列化复杂对象。 Protocol Buffers由 Google 开源基于 IDL 语言定义格式编译器生成对象访问代码。性能高效占用空间小但是需要提前定义 Schema。 ThriftFacebook 开源与 Protocol Buffers 类似。定制生态不如 PB 完善但是支持多语言交互。 AvroHadoop 生态圈序列化框架支持数据隔离与进化动态读写性能可靠性好占用空间较小。但是使用复杂通用性较差。 Hessian一款开源的二进制远程通讯协议使用简单方法提供了RMI功能主要用于面向对象的消息通信。支持跨平台、多语言支持、使用简单缺点是传递复杂对象性能会下降不适合安全性高的应用。 如果兼容性要求不高可以选择 JSON如果要求效率以及传输数据量越小越好则 PB/Thrift/Avro/Hessian 更合适。 数据落库选型 像日志这种大数据量落库都是新增且无修改得场景建议使用 Clickhouse 进行存储好处是相同数据量下对比 MySQL 占用存储更少查询速度更快坏处就是并发查询性能比较低相比 MySQL 使用不算那么成熟。 最后聊两句 到这里本文所介绍三个线上业务优化实战就讲完了其实这种实战案例还有很多但是碍于篇幅本文就没讲那么多拉后续有机会也会继续更新这类文章希望大家能够喜欢。 文章转载自waynaqua
原文链接https://www.cnblogs.com/waynaqua/p/17893173.html
