用户中心，1亿数据，架构如何设计？( 三 ) _架构

对于这一类业务，应该采用“前台与后台分离”的架构方案。
什么是，前台与后台分离的架构方案？

文章插图

用户侧前台业务需求架构依然不变，产品运营侧后台业务需求则抽取独立的 web / service / db 来支持，解除系统之间的耦合，对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务：
（1）可以去掉service层，在运营后台web层通过dao直接访问db；
（2）不需要反向代理，不需要集群冗余；
（3）不需要访问实时库，可以通过MQ或者线下异步同步数据；
（4）在数据库非常大的情况下，可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案；

文章插图

总结
用户中心，是典型的“单KEY”类业务，这一类业务，都可以使用上述架构方案。
常见的数据库水平切分方式有两种：
（1）范围法；
（2）哈希法；
水平切分后碰到的问题是：
（1）通过uid属性查询能直接定位到库，通过非uid属性查询不能定位到库；
非uid属性查询，有两类典型的业务：
（1）用户侧，前台访问，单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高；
（2）运营侧，后台访问，根据产品、运营需求，访问模式各异，基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格；
针对这两类业务，架构设计的思路是：
（1）用户侧，采用“建立非uid属性到uid的映射关系”的架构方案；
（2）运营侧，采用“前台与后台分离”的架构方案；
前台用户侧，“建立非uid属性到uid的映射关系”，有四种常见的实践：
（1）索引表法：数据库中记录login_name与uid的映射关系；
（2）缓存映射法：缓存中记录login_name与uid的映射关系；
（3）生成uid法：login_name生成uid；
（4）基因法：login_name基因融入uid；
后台运营侧，“前台与后台分离”的最佳实践是：
（1）前台、后台系统 web/service/db 分离解耦，避免后台低效查询引发前台查询抖动；
（2）可以采用数据冗余的设计方式；
（3）可以采用“外置索引”（例如ES搜索系统）或者“大数据处理”（例如HIVE）来满足后台变态的查询需求；
任何脱离业务的架构设计都是耍流氓。
来源公众号：架构师之路
作者：58沈剑

【用户中心，1亿数据，架构如何设计？】