jeffrey-hua

1、扫描福字，这里涉及到识别算法，具体怎么识别的，没想明白，还望专业人员讲解。这里涉及到高可用和高并发； 2、根据各自算法，判断是否给福，给什么福； 3、给了福字，就该考虑怎么存储了，由于用户会经常性的查看福字收集情况，所以读操作很多，同时，写操作也是实时存在的，如扫福字得福，请求朋友或者发送给朋友。这种情况的话，加缓存是必须的，但是也存在频繁修改缓存的情况，请求或者赠送也涉及到事务问题，与交易类似，加一减一问题。数据存储特点，参与人数多，数据存储数量大，存储信息小。 我自己想到的是用redis集群存储，并且需要分表，分库得看情况，实现读写分离。入库也是必要的，其实还要大数据处理，分析用户行为，为以后类似活动提供依据。 个人愚见，期待大神给出专业思路。

17年1月刚入职新公司，没年终奖，发了过年礼盒。

不用考虑扩展的话，活跃非活跃用1位(0,1)就可以了，用户类型需要3位(000,001,010,011,100)，这样的话，理论上，1M可以存储2097152个用户，1亿用户也只是几十兆的问题。 但是如果活跃级别变多的话，这样设计不易扩展了，所以基本会考虑预留位来做扩充的。还需要考虑唯一属性来区分用户，用户也可能有其他属性，所以说基本上几十兆存储不了1亿用户信息。 期待大神们给出专业的设计。

基本一致稳定在80kg。

年前80kg，年后也是，浮动在1kg之间。