Skip to content

Latest commit

 

History

History
66 lines (41 loc) · 3.08 KB

项目设计.md

File metadata and controls

66 lines (41 loc) · 3.08 KB

[toc]

如何设计一个文件上传接口,10000条数据。

  1. 保证自己的接口响应时间不能太长。
  2. 保证自己的
  3. 一定要去异步处理
  4. 数据的存储问题。不非得是去存储1W条数据呢。
  5. 可以去异步下单。
  6. 还要去考虑,数据库字段的存储问题。

抽奖

  1. 概率
  2. 时间场次
  3. 奖品

分布式发号器

我咋设计?

  1. 首先他的功能是什么?

    提供一个全局唯一的id。

  2. 是有一个生成中心,然后所有的站点,都来生成中心,然后来获取么?

解决办法:

  1. 使用hash分表。这种情况下,就是如果一个数据库突然挂了,或者新加一个机器,就会有问题。
  2. 雪花算法,这个东西,应该很难吧?
  3. 海波之前说过,是用go去mysql取,每次取1000个,等没有的话,再去数据库取。
  4. 龙哥之前说过的方案,也可以把?使用redis作为计数器,等redis中没有了,再使用分布式锁,再去mysql里面去取一下。
SnowFlake产生的ID是一个64位的整型,结构如下(每一部分用“-”符号分隔):
(1)1位:标识部分,在java中由于long的最高位是符号位,正数是0,负数是1,一般生成的ID为正数,所以为0;
(2)41位:时间戳部分,这个是毫秒级的时间,一般实现上不会存储当前的时间戳,而是时间戳的差值(当前时间-固定的开始时间),这样可以使产生的ID从更小值开始;41位的时间戳可以使用69年,(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年;
(3)10位:节点部分,Twitter实现中使用前5位作为数据中心标识,后5位作为机器标识,可以部署1024个节点;
(4)12位:序列号部分,支持同一毫秒内同一个节点可以生成4096个ID;

执行下线的操作,每次10000条数据,然后去操作下线,说说你的设计想法?其实就是通过一个请求将1w条数据弄到数据库里面?以及如何返回数据。

主要存在的问题,接口连接超时的问题。

什么时候提交,什么时候处理,什么时候反馈给运营方。主要是会有NGINX超时的问题。

主要考察点,怎么拆分,怎么入库,怎么异步处理数据,怎么反馈给前端。这样一个流畅的功能。

  1. 如何去做表的拆分和处理,如何去触发。怎么处理这批数据,如何反馈给运营方。就是一个思路

  2. 文件如何存储。这1w条数据存储到数据库里面。

  3. 如何设计表。字段的选择也是一个考点,比如1w条数据,可以每20条存储一次。

  4. 如何异步处理这批数据,比如完成下线的操作。

  5. 如何返回给客户端。

  6. 入库

  7. 分表

  8. 异步处理,处理完,掉接口,返回值处理。

这设计个啥?把id传过来,立马入 redis ,或者入mq,返回个提示,然后搞个请求监听结果 可以是tcp 或者轮询(弄个等待时间,没有返回放弃,等待刷新)。后台开启个进程,处理,处理一个 存储一个,并修改 通知显示的数据