建设网站 托管 费用,网站建设导航栏变化,佛山网站改版,手机创建微信公众号前言: 之前在某大型保险公司担任技术经理#xff0c;负责优化话务系统模块#xff0c;由于系统已经运行10年之久#xff0c;尤其在话务系统中#xff0c;沉积了几十亿的话务信息表#xff0c;业务人员反馈#xff0c;话务系统历史数据查询部分已经完全查询不动#xff0…前言: 之前在某大型保险公司担任技术经理负责优化话务系统模块由于系统已经运行10年之久尤其在话务系统中沉积了几十亿的话务信息表业务人员反馈话务系统历史数据查询部分已经完全查询不动且数据增量仍然已每天200w以上数据库频繁报警优化迫在眉睫。在我接手之前该系统已经经历过几个版本的优化。1 冷热分离热表存储三个月内数据历史表存储历史数据每天凌晨通过oracle的存储过程迁移。同时通过修改业务页面上加了个按钮是否查询历史数据如果查询历史数据需要勾选上当然在如此大的数据量面前即使勾选上也是查询不出来的页面上无限转圈功能处于不可用状态。2 请了外援由某为公司优化当时给的方案是所有数据使用gaussdb存储通过设置分片分区键改动原有业务单独启动一个jar包提供接口服务集成了mybatils通过sql拦截器校验如果有sql没有带上分区或者分片键则不给查询。最后所有的查询就变成了 select * from xxx where 分区键 and 分片键 数据迁移部分利用过年放假期间采用停机迁移的方式。新版本改动较大虽然经历了较长时间的测试但是也不敢保证不出问题所以在业务测也保留了原有业务随时切换到原有业务业务代码变成了这样。if(开启新业务) {http.post();
} else {原有业务代码
}据老员工说这次改动性能确实不错相关查询处于可用的状态但是数据库稳定性不高经常报警也不是很稳定后来由于大领导们的某些不可控因素合作终止gaussdb没人维护自然这个方案也就被否决了。3 这时候我入职了这部分优化工作就落到了我的头上由于公司和腾讯合作免费提供了Tbase给我们应用这样的话我们就可以采用华为的思路用Tbase替代了gaussdb同时做了sql的适配。做了技术预研只分配了一个分片键的数据到数据库中大概4000多w的数据用时间做分区效果还是不理想业务侧需求是至少每次查询要查询一个月内的数据由于还要通过其他表的数据来做关联查询sql是这样的select * from a left join b left join c left join dabcd四张表都是上亿的数据虽然有分片分区键效果仍然很差只有时间范围精确到天的时候才能做到秒级响应也就是页面上的筛选条件需要由月 改成 天但是这样业务员是无法接受的。4 第四版优化由于第三版技术调研失败我们换了个思路利用大数据组件来做这部分优化。思路是 通过Elasticsearch来做条件筛选里面存储话务表的id然后通过id去Hbase做数据查询。通过技术调研将一个省分的全量数据放到es和hbase后通过省份做es的分片查询可以做到秒级返回。但是这样就涉及到了数据同步问题如果做到Tbase数据表 -》 es hbase因为我们在关系型数据库同步到eshbase的时候由于数据类型以及业务逻辑不一样是需要做比较重的逻辑处理所以这部分只能通过代码实现于是写了一个数据同步组件。数据同步组件包含两部分一部分是离线历史数据同步还有实时数据同步实时数据同步架构如下。注意这里由于数据同步需要保证顺序性需要保证kafka的同一个partition只有一个消费者在消费这里kafka的分区设置策略需要设置成range代码如下import org.apache.kafka.clients.consumer.*;import java.util.*;public class MyConsumer {public static void main(String[] args) {Properties props new Properties();props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, localhost:9092);props.put(ConsumerConfig.GROUP_ID_CONFIG, my_consumer_group);props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, org.apache.kafka.common.serialization.StringDeserializer);props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, org.apache.kafka.common.serialization.StringDeserializer);props.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, range);KafkaConsumerString, String consumer new KafkaConsumer(props);consumer.subscribe(Arrays.asList(my_topic));try {while (true) {ConsumerRecordsString, String records consumer.poll(Duration.ofMillis(100));for (ConsumerRecordString, String record : records) {System.out.println(Received message: record.value());}}} catch (Exception e) {e.printStackTrace();} finally {consumer.close();}}
}
这个架构在很多场景都得到了验证例如上百亿的保单表也是这么存储的Hbase存储保单详情es存储查询条件。至此问题得到了比较完善的解决这里面还存在很多细节问题比如数据同步组件包含两个方面一个是离线同步一个是实时同步。离线数据同步部分要支持不停机同步这部分内容比较多下一篇在介绍吧。
