思考

1.编写代码

问题

用户用手机号码登录的时候，通常需要发送验证码，怎么防止用户恶意地重复发送验证码？写下你的思路和关键代码。重点是要避免误伤。

思路

1. 前端在点击发送验证码按钮加一个令牌,防止用户重复误点。
2. 后端使用redis的hash结构来记录手机号，用户的验证码，发送时间以及场景。

hmset sms_13517626371 code 7635 send_time '2023-08-18 10:11:12' scene 'login'

3. 当用户短时间内第二次误点击发送按钮时，做一个发送时间和当前时间的时间差的判断即可。

伪代码

if (DateUtil.between(DateUtil.parse(DateUtil.now()), DateUtil.parse(redisTemplate.opsForHash().get(send_time)), DateUnit.SECONDS) < 60) {
    thorw new BusinessException(100010, '请不要重复发送验证码');
}
Map<String, String> map = new HashMap<String, String>();
map.put("code"， sms_code);
map.put("sned_time"， "2023-08-18 10:11:12");
map.put("scene"， "login");
redisTemplate.opsForHash().putAll("sms_" + mobile, map);
redisTemplate.expire("sms_"+mobile, 60, TimeUnit.SECONDS);

//调用发送验证码运营商接口

2.编写代码

问题

现在有一个到处EXCEL表格数据的接口，因为数据量过大，还有关联数据查询，倒出时间过长，如何解决这个问题，请写出思路和关键代码

思路

1. 导出时间过长后端响应前端超时，用户无感知，前端可以添加一个导出进度条。
2. 数据量过大会导致OOM，可将excel分片导出多个文件。
3. SQL优化，考虑索引是否命中, 考虑查询基数过大，SQL遍历数据遍历了很多无关数据。
4. 临时表+数据同步, 基于业务考虑，最大化查询效率，研发成本会上升，定时将连表查询的数据同步到临时表，对于导出的结果集只需要查询这张临时表即可。

伪代码

// index: 当前分片
// 

3.设计架构

对于一个每天有100万笔订单的商户平台，大概几万个商户，设计一个架构或独立的服务或集群，每天凌晨生成前一天的每个运营商的对账单，包括总订单数，总金额，订单明细等；要求半小时间左右完成。

思路

每天100W的数据，几W的商户，均算下来一个商户每天100单，1年3W多笔订单，3年就是10W条数据， 数据量不多，所以按照商户id的方式分表，考虑到按照订单号来查询十分不方便，最差可能需要查询所有的订单明细表，所以需要添加一个用户和订单的关联表。现在对于单个商户的明细表数据量就非常的小了，一年也只有3W的数据量，就算后续业务量上来，查询速度也是飞快的。

通过以上设计可得：

1. 单个商户订单明细都在同一张表内。
2. 几W个商户通过hash的方式落到不同的表中。
3. 一张订单明细表存在多个商户，考虑表容量控制在500W内即可，具体多少商户存放在同一张表可计算获取。
4. 新增的用户和订单的关联表可加快以订单号维度的查询。

4.设计架构

对于一个每天有100万笔订单的商户平台，需要增加多种支付方式(微信、支付宝、各种独立第三方，钱包)，支付到独立的商户（每个商户都可以配置自己的收款账户），需要架构灵活，以及对账方便，可热更新切换，写出关键的设计思路，可以提供一些伪代码。

思路

这道题基于第三题的设计架构思路，单个商户的订单明细表都在同一张表内，而且分表也是基于商户ID做hash分布的，所以对账不仅方便，查询速度也非常的快。如需考虑支付方式维度的对账，可在订单明细表新增支付方式字段。

至于考虑支付方式的热更新切换，则需要新增一张商户收款账户表,存放以下字段：商户id, 支付方式， 账户名， 账户密码, 是否禁用，商户和支付方式的映射为1对多。这样就可以控制每个商户账户的新增和禁用。

5.设计架构

设计可以支撑1000W备连接的物联网平台架构，描述技术选型，以及背后的逻辑，没有经历过可以假设，这种场景也类似直播间/游戏/聊天，海量连接的情况下如何让系统更见状，具有扩展性，可观测性。

思路

技术选型

• java
• springboot
• tio

考虑的点

1. tio VS netty, tio对研发更加友好。tio提供的接口和业务有关联，直接使用即可，无需太多考虑网络内容。而netty的非常考验研发的经验，即使是资深研发也难免会出现OOM和死锁的情况。tio支持的协议较少，只有http,wensocket,mqtt。
2. 官方压测数据 tio VS netty, tio在1.9G内存下可以稳定的跑到30W的连接数，可见内存占用极低。对于连接数不是过大的物联网平台，非常建议使用tio。
3. tio官方提供了云平台的付费平台。这也给企业铺了后路，无论是连接数过大，还是系统稳定性和可监测模块都有保障。 4.文档丰富度以及社区维护程度， 框架的维护周期也很重要，随着技术迭代更新，如果框架官方也随着迭代，也保障了使用者的安全和稳定性。 5.团队对于网络编程的能力。有资深的网络编程研发可考虑netty,没有的话，tio更容易搭建起稳定的平台。