搜索到
8
篇与
的结果
-
随手记-为了保证实时一致需要使用强制事务 随手记-为了保证实时一致需要使用强制事务 事务相关原则 强制事务保证实时一致：为确保数据在任何时刻的一致性，对于一些关键场景需要使用强制事务来保障数据的实时准确性。 互联网强调最终一致：在互联网环境中，允许业务线在时间轴上的某个阶段数据和动作存在不一致情况，但最终必须保证数据的一致性。 第三方交互的消息机制：当与第三方系统进行交互时，务必采用消息机制作为中间层，以避免第三方系统的问题导致自身系统被拖垮。 消息中间件应用场景 大数据量请求扩展：主要用于减少系统中重要业务的压力，可处理大数据量请求。不过并非所有请求都适合用消息中间件异步处理，对于像ajax的主要业务且需要实时更新数据的情况，仍需采用同步方式。 特殊消息类型： 顺序消息：在一些业务场景中，如订单下单后通知出库信息，若消息顺序错误，可能导致报表统计数据不一致，所以需要保证消息顺序。同时存在后发消息先被消费的可能，因此要处理好顺序消息。 定时消息：按照设定的时间进行消息发送。 重复消息：当消费者未响应时，投递者会重复投递消息，例如气象系统通知消息。且要保证消息的幂等性，即无论消息投递多少次，都不会影响请求或数据的一致性，如订单通知始终只对应一条订单操作。 高并发场景：例如直播业务中更新粉丝数的操作，可利用消息中间件应对高并发情况。 消息中间件对比 RabbitMQ：其特点是放弃一定的吞吐量来保证数据一致性，当达到一定吞吐量时，可能需要进行特定的定制。 RocketMQ：目前已不再进行维护。 KafkaMQ：具有高吞吐量，但数据一致性表现不佳，存在数据丢失的风险。 DRDs（分布式关系型数据库服务） DRDs通过member_id来定位数据库，用于分布式数据库的管理和数据定位。 TXC（Taobao Transaction Construction） 数据库事务业务场景：由于单库存储在容量和性能上存在限制，TXC可用于解决分布式数据库事务相关问题，以满足业务需求。 分布式session处理：在分布式系统中，需要将session存放在redis中，以保证在不同节点间session的共享和一致性。 下订单业务示例 操作消耗差异：下订单操作中，insert操作消耗相对较低，而update操作消耗较高。在高并发情况下，为避免性能瓶颈，需要将update等操作进行异步化处理。 消息中间件与事务：消息中间件无法保证消息一定能发送成功，且本身不支持事务。但在分布式系统中，可通过半事务机制实现最终一致性。 半事务理解： 第一次理解：客户端以分布式、高并发的方式发送消息给消息中间件，而消费者（服务端）在消费消息时必须遵循事务规则（此理解可能存在错误）。 第二次理解：对于分布式事务，假设有两个存在先后顺序的事务，如事务1为消费10，事务2为增加10。通过消息中间件处理，事务1的消息发送给消息中间件后，消费者可消费事务1，但事务2必须在事务1执行完成后才能启动。 消费顺序：以双十一的下订单、付款、扣款流程为例，消费者必须按照事务的执行顺序，先消费下订单消息并提示用户下订单成功，接着处理付款消息并提示付款成功，最后进行扣款操作。按照这样的顺序逐步实现业务逻辑，以保证业务流程的正确和数据的一致性。 -
大话程序猿眼里的高并发 大话程序猿眼里的高并发 简单理解高并发 高并发指的是在同一时间点，有很多用户同时访问某个URL地址。例如淘宝的双11、双12活动，贴吧的爆吧事件（恶意的高并发请求，即DDOS攻击）。简单来说，就像玩游戏中被ADC暴击了一样，伤害巨大。 高并发带来的后果 服务端：站点服务器/DB服务器资源被占满崩溃，数据存储和更新结果与理想设计不一致（如重复的数据记录，多次添加用户积分等）。 用户角度：页面卡顿，用户体验差，可能导致用户流失。 我的经历：在开发公司产品网站时，经常会有类似抽奖、签到、积分竞拍等功能需求。如果未考虑高并发下的数据处理，可能会导致数据异常，影响用户体验。 实例分析 并发下的数据处理 通过表设计（如记录表添加唯一约束）、使用事务防止并发下的数据错乱问题，以及通过服务端锁进程防止并发下的数据错乱问题。 例子1：签到功能 需求：一天一个用户只能签到一次，签到成功后用户获取一个积分。 已知表：用户表，包含积分字段。 设计： 添加一张签到记录表，并将用户唯一标识字段（ID, Token）和签到日期字段设为唯一约束或索引。 在代码逻辑中，先执行签到数据的添加，再进行积分的添加。 所有操作写在一个SQL事务里，确保数据一致性。 例子2：抽奖功能 需求：抽奖一次消耗一个积分，抽奖中奖后编辑剩余奖品总数。当剩余奖品总数为0或用户积分为0时无法进行抽奖。 已知表：用户表（包含积分字段），奖品表（包含奖品剩余数量字段）。 设计： 在事务中，通过WITH (UPDLOCK)锁住商品表，或更新表的奖品剩余数量和最后编辑时间字段来锁定数据行。 进行用户积分的消耗，完成后提交事务，失败则回滚。 例子3：缓存数据到Cache 需求：当缓存不存在时从数据库获取并保存到缓存中；每天10点必须更新一次，其他时间点缓存两小时更新一次。 问题：10点时有很多并发请求同时过来，导致大量SQL查询操作，增加服务器压力。 解决：C#通过lock机制，在从数据库读取到缓存的代码前加上锁，确保只有一个请求是从数据库获取数据，其他都从缓存中获取。 访问量大的数据统计接口 需求：用户行为数据统计接口，记录商品展示次数等。 问题：大量用户同时在线访问页面会导致大量请求，给服务器带来巨大压力。 解决：通过Node.js写一个数据处理接口，把统计数据先存到Redis的list里，然后再同步到MySQL数据库中。这样可以减少数据库压力，加快响应速度。 高并发下的服务器压力均衡 服务器代理Nginx：做服务器的负载均衡，分散压力到多台服务器。 集群部署：MySQL数据库、Redis服务器或MongoDB服务器，常用查询数据保存到NoSQL DB中，减少数据库压力。 数据缓存：使用Cache。 编程语言选择：使用具有高并发能力的语言（如Node.js）开发Web接口。 服务器部署：图片服务器分离，静态文件走CDN。 数据库优化：优化查询条件和索引。 消息队列：将数据添加到信息队列（如Redis list）中，再写工具入库。 脚本控制请求：防止用户重复点击导致多余的AJAX请求。 并发测试神器推荐 Apache JMeter Microsoft Web Application Stress Tool Visual Studio 性能负载 文章来源
-
