在2.5亿个整数中找出不重复的整数，内存不足以容纳这2.5亿个整数
分治法
采用 hash 函数的方法，把这 2.5 亿个整数划分到更小的文件中，从而保证每个文件的大小不超过可用的内存大小。然后对每个小文件而言，所有的数据都可以一次性被加载到内存中，因此可以使用 hash_map 或 hash_set 来找到每个小文件中不重复的整数。当处理完所有的文件后就可以找出这 2.5 亿个整数中所有的不重复的整数。
位图法
对于整数相关的算法的求解，位图法是一种非常实用的算法。对本题而言，如果可用的内存空间超过 1GB 就可以使用这种方法。具体思路：
假设整数占用 4B（如果占用 8B，则求解思路类似，只不过需要占用更大的内存），也就是 32bit，可以表示的整数的个数为 232。由于本题只查找不重复的数，而不关心具体数字出现的次数，因此可以分别使用 2 个 bit 来表示各个数字的状态：用 00 表示这个数字没有出现过，01 表示出现过 1 次，10 表示出现了多次， 11 暂不使用。
根据上面的逻辑，在遍历这 2.5 亿个整数时，如果这个整数对应的位图中的位为 00，那么就修改成 01；如果为 01，则修改为 10；如果为 10，则保持原值不变。这样当所有数据遍历完成后，可以再遍历一遍位图，位图中值为 01 的 bit 对应的数字就是没有重复的数字。
大文件上传如何做断点续传
由于整个上传过程是按切片维度进行的，且mkfile接口是在所有切片上传完成后由客户端主动调用的，因此断点续传的实现也十分简单：
在切片上传成功后，保存已上传的切片信息
当下次传输相同文件时，遍历切片列表，只选择未上传的切片进行上传
所有切片上传完毕后，再调用mkfile接口通知服务端进行文件合并
因此问题就落在了如何保存已上传切片的信息了，保存一般有两种策略
1.可以通过locaStorage等方式保存在前端浏览器中，这种方式不依赖于服务端，实现起来也比较方便，缺点在于如果用户清除了本地文件，会导致上传记录丢失
2.服务端本身知道哪些切片已经上传，因此可以由服务端额外提供一个根据文件context查询已上传切片的接口，在上传文件前调用该文件的历史上传记录
分布式幂等性如何设计
解决方案
- 查询和删除不在幂等讨论范围，查询肯定没有幂等的说，删除：第一次删除成功后，后面来删 除直接返回0 ，也是返回成功。
- 建唯一索引：唯一索引或唯一组合索引来防止新增数据存在脏数据 （当表存在唯一索引，并发 时新增异常时，再查询一次就可以了，数据应该已经存在了，返回结果即可）。
- token机制：由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交。前端 在数据提交前要向后端服务的申请token ，token放到 Redis 或 JVM 内存，token有效时间。提交后
后台校验token ，同时删除token ，生成新的token返回。 redis要用删除操作来判断token ，删除成 功代表token校验通过，如果用select+delete来校验token ，存在并发问题，不建议使用。
悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用（另外还要考 虑id是否为主键，如果id不是主键或者不是 - 乐观锁，给数据库表增加一个version字段，可以通过这个字段来判断是否已经被修改了
Zookeeper 的分布式锁。单号为key，然后给Key设置有效期（防止支 付失败后，锁一直不释放），来一个请求使用订单号生成一把锁，业务代码执行完成后再释放锁。
7 ，保底方案，先查询是否存在此单，不存在进行支付，存在就直接返回支付结果。