1.电商往往会涉及到资金的流转，在后端方面如何保证资金在电商平台上的安全？
-
如何确保用户账户、支付信息不被篡改或盗用？
-
可以采用双重身份验证，引入短信验证码、邮箱验证码进行二次验证
-
用户支付密码需要避免明文存储，可以采用 PBKDF2 或者 Argon2 哈希存储
-
防止暴力破解，限制支付密码输入错误次数，超过阈值后进行账户锁定或额外验证
-
补充：
- PBKDF2（Password-Based Key Derivation Function 2）会对密码进行多次加密，让破解变得非常困难
- 原理：用户输入密码，例如
mypassword123，系统给它加点“盐”（随机数据），比如randomsalt，再用 PBKDF2 算法反复进行哈希运算，得到最终的哈希值，存入数据库
- 原理：用户输入密码，例如
- Argon2 是一种更先进的哈希算法，相比 PBKDF2，它不仅反复 “加密” ，还让计算过程 更吃内存，这样黑客即使使用高性能 GPU 或专门的破解硬件，也很难暴力破解
- PBKDF2（Password-Based Key Derivation Function 2）会对密码进行多次加密，让破解变得非常困难
-
-
如何保证用户支付、退款等资金操作不会因为系统异常导致资金错账或丢失？
- 采用分布式事务保障
- TCC 事务机制：Try 预留资金（冻结余额）、Confirm 确认扣款（实际转账）、Cancel 取消预留（释放资金）
- SAGA 事务模式：长事务，如跨行转账，采用补偿机制回滚失败操作
- 消息事务 + 幂等处理：采用 RocketMQ 的半消息机制实现消息事务，支付成功后发送事务消息到 MQ，再异步更新订单状态。注意订单状态更新必须是 幂等的，防止消息重复消费
- 对账机制
- 定期对账（商户、银行、用户对账），发现差异立即报警
- 记录交易日志，提高不可篡改性
-
补充：
-
TCC（Try-Confirm-Cancel）是一种 两阶段提交（2PC） 的思想（TCC 可以保证事务操作的严格执行，不会出现一部分成功，一部分失败的情况），核心思路是：“先预留资源，再真正提交，失败后回滚” 。举个例子，你去餐厅订了一桌火锅，整个流程是这样的：
-
Try（尝试扣留资源）：你打电话订座，餐厅告诉你“位置已预留”，但还没真正让你入座
-
Confirm（确认执行）：你准时到达餐厅，餐厅正式给你安排座位，你可以开始吃火锅了
-
Cancel（取消执行）：如果你临时有事不去了，餐厅会把你的座位释放出来，别人可以预订
-
-
SAGA（补偿事务）模式，是一种长事务管理模式，适用于 异步、非实时的业务。核心思路是：“如果某个步骤失败，就执行补偿操作撤销已完成的步骤” 。
-
假设你在电商平台下单：
-
用户下单，订单服务创建订单
-
扣减库存
-
扣款支付
-
通知商家发货
-
-
如果第 4 步失败了（比如商家没货），SAGA 需要执行补偿操作：
-
退款
-
回复库存
-
取消订单
-
与 TCC 不同的是，SAGA 不用预留资源，而是进行补偿操作，更适合长时间运行的事务，比如机票预订、物流订单等
-
-
-
- 采用分布式事务保障
-
如何防止恶意用户利用支付系统进行欺诈或盗刷？
-
结合 IP、设备指纹、地理位置、交易习惯 进行用户风险评分
-
黑名单系统，记录欺诈用户、异常设备、IP 段，拒绝高风险交易
-
-
如何确保支付系统 24 小时高可用，不因系统故障影响资金流转？
-
多活架构，采用 双机房 + 多活部署（如主流银行的两地三中心）
-
负载均衡，进行流量分发，避免单点故障
-
Raft/Paxos 分布式一致性协议，保证支付系统在节点故障时可自动切换
-
定期进行 容灾演练，确保故障时可以快速恢复
-
2.为什么使用 RocketMQ 而不是其他的消息队列？
- 商城项目往往会有很高的在线人数，需要高吞吐量，RabbitMQ 就不适合高吞吐场景
- 电商场景下，要求整体延迟低，RocketMQ 在延迟方面表现更好，适合金融、电商等场景
- 电商平台中，订单、交易等场景需要保证消息的消费顺序，RocketMQ 支持全局顺序消息和分区顺序消息，适合需要严格顺序的场景
- RocketMQ 使用 java 开发，和项目联系更紧密
RocketMQ 顺序消息如何实现？
- 确保同一业务的消息 按顺序 发送到同一个队列中，并由同一个消费者线程 按顺序 消费
- 队列锁机制：每个 queue 都分配一个锁，确保同一时间只有一个线程消费该 queue 的消息，这样可以避免多个线程同时消费同一个 queue 导致消息乱序
- 消费者 在本地维护一个队列，按照消息的存储顺序逐个处理
- 消息消费失败，RocketMQ 会将消息重新放入队列，等待下一次消费