1,划分核心非核心功能,例如游戏的接入业务中,登录注册校验为核心功能,msg和日志为非核心功能,DB,server和cache都需要物理隔离,只要核心非核心存在共享资源,如DB公用1个,要是非核心出现大量整表查询,核心功能会受到影响,核心和非核心之间采用接口访问。
2,一张大表拆分到不同DB,来提升数据库性能。DB分为4个分库,模值为1024,每个分库占据256个位置,hash (test1234) = 3109729401 % 1024 = 537 在分库3.扩容方式:原分库分割为2个,每个分库占据128个位置。
3,针对hbase存储log收集系统。log表存储日志记录,meta表存储索引元数据(包含动态索引index表的名称),动态index表:存索引的具体信息,一个索引对应1张表。log列族:tag存储日志taf(如tag_LEVEL,tag_TIME,tag_HOST),message存储日志信息。meta表列族:index作用含2个,qualifile,name和span,那么存索引名称,span是索引使用的时间间隔。动态索引表:rowkey是json格式的indexRowkey字符串,如["tags":["INFO"],time: 2342343]。获取日志产生的时间,然后内部存储1个tag是的循环,匹配则为其建索引,往索引表插入1条数据。
4,定制360Altas,会做sql分组,数据库分组,哪些SQL到哪些DB。单独服务拆分成小系统,对DB每个月做DB容量的review,分析哪些表是大表,读写的QPS和容量。
5,支付则需要强事务DB,很多社交平台需要高可用,有的则关心几天的数据,有的频繁access历史数据,有的可以加index,有的只能cache,做各种水平和垂直提升DB访问量,缓存机制分流。
6,数据库按模块进行迁移拆分:价格 产品 用户 基础设施 订单 商品等,只需要修改数据库连接即可,而对于表字段优化,以SOA收口/应用重构来实现,模块根据业务规模和系统复杂度实现,表名:模块缩写+表名,自增:表名+ID,模块之间减少关联,DB之间不允许join和连接。
7,一号店订单拆分,mod分库比较多,二次分库数据迁移方便,多库简单查询,如带有groupby orderby avg等,建议DAL汇总单个库返回的结果,如按照时间顺序查询订单,没每页面100条,需要遍历所有DB,每个DB中取得前100条,8个汇总为800条,在应用中二次排序,最后取得前面100条。如取第10页数据,汇总后有8000条,读着8000条二次排序后取(900,1000)条记录。
8,外卖涉及三个查询维度:订单ID,用户ID,门店ID,以一定的规则存储每个维度不同的分片,同时按照三个维度多查查询时,数据均在同一个分片。实现1个轻量级的分库分表插件,在业务代码上几个要点:配置文件管理分库分表配置,java注解说明sql语句分库分表,AOP解析注解+查询配置文件获取DB源和表名等,mybatis动态替换表名,spring动态替换数据源,对于ID,用户ID 门店ID外查询(如按照手机号前缀查询)等效率查询,用ES搜索支持,用databus等将订单数据同步到ES,利用批量写入来降低ES写入压力,利用ES分片支持扩展。
9,DB以uid分库分表,二叉树分库,1台->2 台, 2->4,4->8,每个库10个表,订单系统ID为全局唯一序列,利用DB的序列,通过内存计算获取全局唯一的订单ID,三部分组成:毫秒时间,服务器编号,自增序号。
10,,
2.zk序列:zk序列其实实现了2种,一种是通过zk来协调的非递增,另外一种zk递增方式,递增方式内部实现思路与db方式有点类似,每个表一个序列,然后有个序列步长范围。
3.时间戳方式其实就是Twitter的snowflake,需要每个mycat实例配置的WORKID,DATAACENTERID不同,这块还可以优化下把这个配置放zk上去。
顺便提下:mysql下主键肯定要自增有序的数字类型主键了,UUID那种是不适合的,一个太长,一个是innodb的特性决定的。