1 场景
旧版的文件管理，封装了 FastDFS 的 API，直接让业务方使用，存在以下问题：
- FastDFS 未提供权限管理、审计功能，管理上存在风险
- 业务项目使用 SDK 直接访问 FastDFS，不利于后期改造、升级
- 外部链接直接使用 FastDFS 的文件地址拼接，暴露了选型、真实地址
- 外部链接暴露之后无法回收，除非直接删除文件本身
- 外部链接不支持规则校验，只要知道地址就可以随意访问
2 逻辑
架构方面，由 client、service 两部分组成，分为上传模块、下载模块。
t_file 文件记录表，逻辑表 5000万，物理表 15万
t_link 外部链接表
t_rule 访问规则表
3 过程
数据量 7000万+，日增量 14万+，峰时QPS 发生在凌晨业务组批量备份合同等文件 1000+。 申请写权限：读1次MySQL（3000 TPS） + 写1次Redis（7W QPS） 申请读权限：读1次MySQL（3000 TPS） + 写1次Redis（7W QPS） 置换文件ID：读1次Redis（7W QPS）+ 生成分布式ID（400W QPS） + 写1次数据库（3000 TPS）
4 开发
使用 SpringBoot 全家桶开发。
5 物理
分别部署在铜牛、马驹桥，共2个实例。 单机QPS 1000，单边2个实例可以满足 1000+ QPS，在一个机房断电情况下实现高可用。
6 思考与展望
6.1 如何做的分表分库
核心表 t_file 数据量大，一天产生14.6万记录，一年产生1.5亿记录。因此使用日期作为维度分表。 信贷一组 300000 * 5 = 150000 信贷二组 500000 * 5 = 250000
6.2 目前存在什么问题，将来如何发展
- 将来业务创建更多外部连接，那么 t_rule、t_link 会膨胀 场景是读多、写少，可以使用面向文档的 NoSQL 数据库。
