​​一 说明

本期主要集中在大V列表的生成，和周回答率的计算；

写的比较快，可能有少量问题，可以在群内讨论

二 亮点说明

1 【亮点】大V列表的生成

由公司、部门、职位三个要素决定

注：因为P1的设计大家不清楚，说明一下这3个要素的关系 

公司和职位是第一维度的 就是有单独的公司表和职位表 也就是有单独的companyId 和单独的positionId

部门是公司的子表，也就是部门表是与companyId关联的，再关联posititions（逗号分割）

这里给出相关的简化表(只需要考虑关键属性)

1.1 vip_user(用户简表)

1.2 vip_company(公司简表)

1.3 vip_position(职位简表)

1.4 vip_department_position(部门和职位简表)

1.5 数量规则

（1）条件下 >10个

按按分数划分前30%为大大V（取3人），后70%为普通大V（取7人）

问题点：因可能部分大厂大V较多，不方便都查询出来之后，再做随机；

技术方案：sql语句直接返回每段的随机人数（3-7）两次查询；暂不使用redis缓存结果

（2）查询结果 =10

直接返回，按分值从大到小排序

（3）查询结果 <10

从同公司其他部门相同职位补全；依然不足时补充不同公司同职位Top列表。

问题点：数据库查询较多，需要进一步优化性能

技术方案：

1 符合查询条件的（<10）a条数据放到列表前面，按分值从大到小排序

2 从同公司其他部门相同职位补全（与部门无关），

  大于（10-a）则随机出来-》这一步要联查多张表，且大概率出现，需要提高性能-》

  redis每天半夜2点 放每个公司每个职位的前20人，不走数据库查询；所有跨部门的 都走redis 但是需要与本部门去重（redis主键 vip + companyid + positionid）

3 position补全（与公司无关）

 redis每天半夜3点 放每个职位的前50人，不走数据库查询；（redis主键 vip+ positionid）

二 【亮点】周回答率的生成

两天前的处理，每天半夜4点，定时计算更新大V表的数据

性能估算：大大V一周100个帖子 大v平均10个 1万个大V ；每天半夜计算量依然较大

性能优化：暂时大V较少不优化，后序使用ES或者其它数据形式优化

三 服务设计

四 数据表设计

1 xiaozhaoVIP__VV 大V表