0
1
2
3
4
5
0
1
2
3
4
5
1月前来过
java开发专家
杭州全职 · 1000/日 · 21750/月信用正常
工作时间: 周末8:30-17:30工作地点:
服务企业:
3家累计提交:
1工时
联系方式:
********
********
********
****************
查看联系方式
个人介绍
工作经历中开发过的系统：网络、应用监控系统，快的/滴滴打车订单服务，各种im系统（客服im、聊天im、直播im），理财app的账务系统、饿了么外卖APP工作10年+，对于软件架构的方法论有自己的理解，熟悉一般的架构模式大学期间专注于ACM竞赛，编程功底扎实每份工作都担任过师兄角色。有过小团队虚线、实线leader的工作经历平时主要java开发语言，从事后端开发，有过中间件、业务系统的开发经历
工作经历
2019-06-03 -2022-12-05阿里本地生活-饿了么java开发专家
2019.6 ~ 2019.10 饿了么推荐有奖python工程的java化改造；参与***侧的下单后助力返现项目。 2019.10 ~ 2020.6 参与饿了么C端交易日常需求迭代 2020.7~2020.9 接手团队常规性稳定性工作 2020.10~2021.4 作为外卖前台的稳定性owner，搭建稳定性体系 2021.4~2022.12 作为店铺装修业务的技术owner，负责日常需求迭代、性能优化、应用&数据迁移
2017-03-01 -2019-05-3151信用卡java架构师
所在团队：理财技术部 2017.3 ~ 2017.9 1. 凌晨收益任务提速 2. 降低人品宝（我们主要的P2P理财APP）服务端主库压力 3. 大sql优化 4. 人品宝标细胞合并项目 2017.9 ~ 2018.8 内部成立理财账务组，作为小组leader，规划、推动组内工作，具体的内容： 1. 推动&完成存证项目 2. 将之前的分库分表方案简单化，应用于后续的几个表的分库分表操作 3. 规划推动组内核心工作——账务组件化、收益平台化
2015-10-05 -2017-02-28九研科技java高级工程师
所在团队：中间件组 主要工作内容： 1. 建设&维护app推送通道，开发了定向推送&全量推送功能 2. 负责tcp长链接服务 3. 开发各种im系统 3.1 客服im聊天系统 3.2 蕉蕉聊天App的聊天im系统 3.3 in app直播im，1个月做到但直播间支持10万用户同时在线的能力
2014-06-30 -2015-09-30快的打车java工程师
2014年：在快的打车订单组，主要工作内容： 1. 参与订单域的需求开发 2. 负责智能调度项目的研发 3. 负责订单的服务化改造 2015年：快的和滴滴合并，我在滴滴代驾事业部作为公共业务服务的小技术owner，负责几个系统的研发： 1. 公共业务服务 2. 对外api服务 3. 业务配置中心
2010-12-01 -2014-06-13北京广通信达杭州研发中心java工程师
1. 2010.12 ~ 2011.04 (实习) 开发数据同步模块。其中使用 quartz 进行多任务调度。 2. 2011.04 ~ 2011.12 a. 主要负责修正网络监控产品中的bug、同时对不良代码进行各种重构; b. 负责网络监控产品的 oem 工作; c. 参与产品的开发工作; d. 参与研究性工作，如产品的多数据库支持研究。 3. 2012.01 ~ 2012.06 a. 部门中独立出了维护小组，我作为小组负责人，负责网络监控产品的维 护工作; b. 期间也参与过产品新版本的开发。 4. 2012.07 ~ 2012.09 a. 负责存储监控产品的预研工作，为公司日后开发新产品做好准备 (最终 没有实质性进展); b. 负责研究针对虚拟化的监测方案，这里主要是针对vmware、 另外对云计算也有初步的了解。 5. 2012.10 ~ 2013.03 作为开发经理参与应用监控产品新版本的设计、开发工作。 6. 2013.03 ~ 2014.02 从事产品架构工作，主要工作内容为设计、开发产品平台模块，以及产
教育经历
2007-09-01 - 2011-06-01湖州师范学院计算机科学与技术本科
1 获得一等奖学金 2 获得软件设计师证书 3 浙江省acm竞赛三等奖
技能
作品
这是我2015年做的一个功能 1. 功能模块 1.1 滴滴前端-获取后端数据&展示 1.2 滴滴后端-公共服务：根据前端传入的经纬度返回当前定位的二级城市 1.3 高德地图：提供poi服务，用户获取经纬度对应的城市信息 2. 我负责的部分：滴滴后端-公共服务。技术栈：java、dubbo、zk、http 3. 难点 3.1 高德给的接口一直不太稳定，平均rt有100多毫秒，超时时有发生 3.2 qpm从200突然增长到20000，扛不住压力：这个接口一开始只服务于滴滴代驾，后来因为app功能上的调整，滴滴首页打开后就会访问这个接口，导致压力过大。 4. 难点解决 总共有过2个解决思路 4.1 首先是早期提过的在机房内部署本地高德服务，但是一直无法推动 4.2 在即将奔溃的时候，我直接去拉取到了高德的地理围栏数据，其中有各个城市的边界线坐标集合。我将这些数据放到程序的本地缓存中，然后使用多边形算法，最终可以在10微妙内完成城市定位
02023-04-08 02:05
1. 功能模块 1.1 装修前端-商家操作的入口，用于触发套餐配置的增删改查操作 1.2 装修后端-选菜组件&配置存储&下发 1.3 店铺C端后端-配置接收 1.4 店铺C端前端-app页面效果渲染 2. 我负责的部分：装修后端。技术栈：java、hsf、rocketmq、redis、mysql、布隆过滤器 3. 难点 3.1 商家增删改配置：商家可以以连锁店维护对其管理的店铺进行批量操作，1次会为1万个店铺与配置绑定/结绑，同时系统需要在1秒（比上一个顶部招牌的项目要求更高）返回操作结果 3.2 商家查询配置列表：有非常多的过滤条件，比如配置投放日期、投放时间段、投放渠道、投放人群.... 3.3 配置下发接口，并发量非常高，且接口响应时间要求也很高，需要在50ms内返回 3.4 只能增加少量服务器资源 4. 难点解决 3.1 商家增删改性能提升：使用新工程框架来做，对于db操作基于mybatis，只需要几条sql即可完成db操作；对配置关联表进行分表，降低单表数据量。 3.2 商家查询配置列表：在配置变更时，通过rocketmq的事务消息将配置数据同步到es中，通过es来做各种条件过滤查询 3.3 配置下发接口：通过rocketmq的延迟消息，以店铺维度将店铺关联的配置缓存到redis中，请求基本命中redis 3.4 只能增加少量服务器资源：通过业务特点发现有90%以上请求的店铺都是未配置过套餐组件的，所以在本地维护1个有配置记录的店铺id的布隆过滤器，通过redis延迟消息进行维护。最终在大幅度降低配置下发接口耗时的同时，大幅度降低了服务器资源消耗。
02023-04-08 02:32
饿了么店铺详情页-顶部招牌 1. 功能模块 1.1 装修前端-商家操作的入口，用于触发顶部招牌的增删改查操作 1.2 装修后端-配置存储&下发 1.3 店铺C端后端-配置接收 1.4 店铺C端前端-app页面效果渲染 2. 我负责的部分：装修后端。技术栈：java、hsf、binlog、redis、mysql 3. 难点 3.1 商家增删改配置：商家可以以连锁店维护对其管理的店铺进行批量操作，1次会为1万个店铺与配置绑定/结绑，同时系统需要在10秒返回操作结果 3.2 商家查询配置列表：有非常多的过滤条件，比如配置投放日期、投放时间段、投放渠道、投放人群.... 3.3 配置下发接口，并发量非常高，且接口响应时间要求也很高，需要在50ms内返回 4. 难点解决 3.1 商家增删改性能提升：工作量非常有限，所以通过多线程并发操作db来降低接口的总时长 3.2 商家查询配置列表：通过binlog事件将配置数据同步到es中，通过es来做各种条件过滤查询 3.3 配置下发接口：以店铺维度将店铺关联的配置缓存到redis中，请求基本命中redis
02023-04-08 14:39
