猿急送>

北京Java兼职程序员

ID：409565

只颂人间星月

高级java

公司信息：
北京爱启航网络科技有限公司

工作经验：
5年

兼职日薪：
800元/8小时

兼职时间：
下班后
周六
可工作日远程

所在区域：
北京
海淀

技术能力

5年Java开发经验，现就职互联网教育行业，U9领域头部平台，从事分布式、高并发、高可用、大数据量的教育产品的系统
研发。对MySQL、RocketMQ、ES、并发、redis等技术有深入研究。
深入理解JDK集合和并发包常用类原理，研究过volatile的硬件级别原理、线程池的核心源码
深入理解MYSQL 内存模型、存储模型、事务、索引底层工作原理，能根据explain执行计划调优
深入理解Redis数据结构、持久化、主从、集群、分布式锁工作原理，熟悉缓存雪崩、缓存穿透，缓存击穿解决方案
深入理解Elasticsearch、RocketMQ的工作原理，研究过RocketMQ的核心源码
深入理解JVM底层工作原理和垃圾回收机制，熟练使用jstat、jmap、mat及Arthas进行JVM调优并定制JVM模板
熟练掌握Git、SVN版本控制工具，熟练使用Docker、k8s容器化技术

项目经验

某CRM系统
项目背景
教育行业转化链路长、客单价高，需专业销售持续跟进。传统CRM系统无法满足区域分配与灵活规则配置需求，亟需构建高
效线索分配引擎，优化销售转化流程，提升机构竞争力与客户体验。
项目介绍
CRM系统主要包含
站内线索挖掘（名片池管理、自动/手动同步名片、活跃已选/筛选名片、自动活跃名片）
线索分配（线索管理、线索查询/导出、线索分配设置、成员管理、成员分类及上限配置、线索分类管理、分配引擎）
线索跟进（通话记录、外呼账号管理、呼叫）
线索转化（工单汇总、业绩汇总、补提当月业绩、确认当天业绩、销售提成、撞单）等功能。
基于责任链模式和建造者模式实现线索的预分配及分配上下文的初始化，使用 RocketMQ + redis + xxl-job 完成线索的拉
取、分配及历史分配统计信息报表，使用MySQL存储底层数据，针对线索、名片、业绩等大表按年分表，使用ES完成业绩汇
总及线索、名片列表页的聚合查询。
项目职责：系统主要开发者，主要负责智能线索分配引擎的规划与开发及站内线索挖掘、转化等核心功能。
负载情况：名片、线索表年增量500W左右，业绩表年增量300W，高峰期日分配量60W+。
技术挑战
日百万量级线索分配方案设计
问题描述
线索分配时消费逻辑复杂、链路长，导致消费速度慢，MQ消息堆积。
分布式锁锁粒度太大，贯穿整个查找、分配逻辑(包含三方接口调用及重试逻辑)。
消息消费和定时任务执行前均会访问临界资源，添加锁，导致锁冲突概率变高。
解决方案
基于redis预构建销售池，将线索拉取、预分配、分配解耦，线索具体分配给哪个销售，在预分配阶段确定。每完成
一个中心分类池的分配，会实时刷新销售池数据。
线索处理采用分池机制：单批次不超过 1000 条线索，按中心与分类划分至不同线索池。每个线索池依次执行团队内
分配和跨团队分配，未分配线索暂存至暂存池，最终通过溢出分配逻辑实现兜底。
销售池读多写少，当后台修改销售信息或者定时任务兜底执行时构建。为减少冲突，采用异步、加锁机制，锁超时时
间设置为任务执行间隔。
三方分配接口限流10qps，为提高分配性能使用并发调用设置了独立的线程池
实现效果：优化前，单条线索处理耗时存在较大波动区间（358ms - 20s）优化后，单条线索平均耗时约为 171ms，性
能提升幅度达52.23% - 99.15%
三方分配接口限流10qps，为提高分配性能使用并发调用设置了独立的线程池
问题描述：名片表及线索表数据量达到千万量级，索引效率降低，查询过慢，后台列表查询速度超过10S。数据插入、更
新慢，慢sql频繁告警。
解决方案：针对对名片及线索大表，将历史数据归档。按年拆分，分表数据量在500W左右。拆分大事务，后台列表基于
es做聚合查询。
实现效果：后台列表查询控制在3S内，大表慢sql无告警