猿急送>

其他Java兼职程序员

ID：285883

Possible

高级Java工程师

公司信息：
北京拓普丰联信息科技股份有限公司

工作经验：
5年

兼职日薪：
500元/8小时

兼职时间：
下班后
周六
周日

所在区域：
其他
全区

技术能力

1. 深刻理解数据结构以及使用场景；
2. 擅长并发编程，深入源码理解 AQS，有良好的并发编程思维和习惯；
3. 熟悉 JVM 工作原理，熟悉 JVM 调优；
4. 熟悉 Netty 的原理和网络编程思想；
5. 深入源码理解 Spring 容器、Bean 的生命周期以及扩展点；
6. 熟练使用 MySQL，熟悉 Oracle、PostgreSQL 等关系型数据库；
7. 熟悉 InnoDB 引擎的原理，熟悉 Mysql 优化技巧；
8. 熟悉 Redis 以及 Redis 常用数据结构，系统了解 MongoDB；
9. 熟悉 RabbitMQ，系统了解 RocketMQ 以及 Kafka；
10. 熟悉 Spring，SpringMVC，Mybatis，Spring-Boot，Spring Cloud Alibaba 等主流框架；
11. 熟练掌握分布式原理，分布式数据一致性，分布式事务原理；
12. 熟悉 Spring-Security 安全框架的工作原理，熟悉 OAuth2.0 认证流程；
13. 熟悉 Elasticsearch 的原理；
14. 熟悉 Zookeeper 的原理和使用。

项目经验

项目名称：拓普事务组件项目时间：2021 年 6 月至 2022 年 3 月部署环境：Ubuntu14 运用技术：Spring，Spring-Boot，Redis，Filebeat，Logstash 背景描述：工商业务系统是工商部门内部的系统，属于内网，不对大众开放，而全程电子化相当于部分工商业务系统的功能开放给普罗大众使用，其间数据必须打通，考虑到业务系统的数据安全性，以数据交换和接口推送的形式来使数据打通，由于内网接口不可能开放给外网访问，故通过一个对外服务平台来作任务调度，定时推送业务审核状态到外网系统，这样一来就有了数据一致性的问题，拓普事务组件就诞生了。该组件由业务端提出需求，项目经理提出解决方案，本人根据需求独自设计代码实现逻辑和技术架构，由于业务组使用的 Spring1.x，JDK1.6，故实现时尽量不依赖第三方的组件。组件实现：控制台：1. 客户端和服务端在此进行应用和节点的注册； 2. 服务端注册接口协议，例如：接口唯一标识，请求协议，请求方式，请求体，建议的请求超时时间，是否接受重试，建议的重试的时间间隔，是否允许错误请求在重试失败后定时补偿，建议补偿的时间（可以多个，精确到分钟），需要重试的错误码（可以多个），建议的补偿次数的上限等； 3. 客户端需要根据服务端提供的接口，注册自己需要调用的接口，并且可以覆盖服务端建议的一些配置，且可以根据节点的性能做个性化的配置； 4. 通过 Filebeat 采集客户端的通过本组件的请求日志、补偿日志、待补偿日志到 Logstash，Logstash 通过数据清洗持久化到控制台； 5. 达到补偿次数上限的数据可以修改请求头，请求路径，请求参数等，然后手动补偿； 6. 根据请求日志作接口调用时长分析的展示（仅成功的），根据应该和接口唯一标识分析接口平均耗时，最长耗时，最短耗时，周期内 1s 以下次数，1s~3s 的次数，3s 以上次数，帮助开发者和运维去了解接口性能和节点性能。
客户端：1. 使用 Appache HttpClient 的连接池来托管客户端对服务端的请求，每次请求都生成一个唯一的标识； 2. 实现每次请求失败重试三次(3s，10s，60s)，使用 ThreadPoolExecutor 和 ScheduleThreadPoolExecutor 来实现异步重试和同步重试，之所以两种配合使用，是防止 ScheduleThreadPoolExecutor 在大量延时任务排队时任务超时导致线程池假死；3. 使用优先级队列根据下个任务的执行时间来排队所有的三次重试都失败的请求，在执行周期到来时取出进行补偿； 4. 提供成功或者失败通知接口，开发者可以根据需要实现此接口，通过注册到 Spring 容器中来收取通知； 5. 提供重试或者补偿前修改 URL，请求头，请求参数的接口，开发者根据需要可以实现此接口，通过注册到 Spring 容器中实现此功能； 6. 通过 Spring 的监听器监听容器的启动，在 Spring 容器启动后立即开启一个周期性去控制台拉去本应用的调用接口的配置；如果无法连接到控制台，则从接口配置的持久化文件中读取，防止控制台宕机导致服务不可用； 7. 在 Spring 容器启动后延时开启一个周期性去持久化本应用的调用接口的配置的任务； 8. 启动补偿队列，读取本地待补偿任务的持久化文件开始根据补偿的时间进行补偿；9. 在 Spring 容器启动后延时开启一个周期性去持久化本应用中优先级队列的待补偿的任务； 10. 监听 Spring 容器销毁事件，在销毁容器时持久化待补偿队列； 11. 监听补偿周期的修改，在补偿周期修改时通过自旋阻塞队列的存取，重排队列，排序完毕后开放队列的存取； 12. 每次请求都会记录一个开始请求的日志和结束请求的日志，日志限制保存大小，每次补偿记录补偿状态，三次重试皆失败的日志，如果在一段时间内大量失败，如 10 分钟内失败超过 1000 笔将邮件通知负责人。服务端：使用 Redis 缓存成功请求对应的请求唯一标识的返回值，保证幂等性。