500万日活app用户表设计，服务化业务边界。

[风姿-懒人]

想讨论下 400万日活的用户表该如何设计，更加合理。 简要信息如下：
1.用户基本信息 类似：手机号码，账号，昵称，邮箱，密码，性别，年龄
2.用户密保信息：密保问题1 密保问题2 答案1 答案2.
3.用户类别信息：是一个普通用户，还是大v，还是其他类型。
4.机型信息：手机imei,手机系统类别，手机厂商，手机型号，系统版本等。
5.登陆信息：登陆时间，最后登陆时间，需要有详细登陆记录，以及登陆时的手机型号等信息，而且用户是感知不到登陆的
6.经验信息：账号等级体系，多少经验增加一个等级 类似1 2 3 4级，初始1级，100经验2级 200 4级类推，经验来源发评论等。
7.积分信息：账号积分体系，积分可以兑换，积分来源做任务，签到等。
8.会员信息：会员开通时间，会员到期时间，开通时长，续费信息等。
9.第三方信息：qq登陆，微信登陆，小米登陆等。
10.其他待补充：

额外要求：
1.所有登陆，注册等行为需要可回溯。类似一个用户换了个手机号码，重新注册了一个账号，需要大概率识别是同一个人。原因：当前互联网用户拉新成本比较高，需要明确知道，当前拉新的用户是否是真正的新用户。

2.账号防止被刷，要能识别出哪些账号是黑厂账号，哪些是正常账号。

3.对app端用户友好，性能OK 要求接口返回等100ms以内。

4.其他待补充

首先是表设置 db使用mysql.

其次是dubbo服务化，将用户进行抽离出来服务化，那么这个应该如何设计好。

希望广大论坛好友帮忙参谋 一起讨论下，如何实现，或者帮忙补充下还有哪些需要注意的地方。

[stacksoverflow]

1.设计历史表，所有登陆，注册行为都存入历史表并且保存尽可能全的请求信息（通过队列写）。 通过对历史表的分析来识别同一用户，黑厂账号等 2.接口返回等100ms以内的话，一般读缓存写队列就可以满足。 3.dubbo服务化的话在保证业务的独立性的前提下按流量拆分服务。

[maradona1984]

俺这房产行业木有没遇到过这么高的日活,你这描述数据库用户记录数怎么也有1000W往上了(低频app就更高了),mysql分表是必然的咯,怎么分那得看你的业务了,或者可以考虑不用mysql,可以考虑用hbase(或者组合使用)

不同手机号要识别同一个用户, 有imei就很简单了,如果还要进一步,那得买别人家数据了
是否黑厂,app集成SDK做用户行为分析是否可行?

服务化前提是数据层要独立,影响最大的还是关联查询,避免跟用户表关联查询,举个例子,查询姓名为张的人的订单数,如果数据库物理隔离,这种查询只能先查出张姓用户的id集合,作为条件查出这些id下的订单(或许有更好的办法,但我没想到)

[风姿-懒人]

针对历史表，这里有个问题，如果用户是登陆注册，那没毛病。问题在于用户一旦登陆，就不会有下次在登陆的行为。
类似我们上美团，肯定只需要等于一次，之后的很长很长一段时间都是不会再登陆的。

[风姿-懒人]

用户账号数据分为2部分。 一部分叫做被动用户，也就是系统自动分配的，一部分为用户自己注册的。 被动分配的数据在4亿左右。
主动注册的也在5000万以上，所以具体表应该如何设计，如何划分边界。主表应该存什么，感觉要细细思考。

[mdzzNO]

您好, 就是我遇到了那个您有个提问的jenkins中deploy没有打印信息, 就是deploy没有成功, 想请问下您最后解决了吗. 实在没有联系方法只能这样找您