高并发场景下国产中间件选型与数据库架构深度实践
老李依据近期项目实战情况，从数据库交互的角度出发，深入地剖析了四类中间件在选型方面的关键要点以及应用落地的相关情况。
一、应用服务器中间件：Java EE 规范与连接池调优
应用服务器属于数据库连接池的直接管理者范畴，其进行选型这一行为，将直接对JDBC连接的获取效率产生影响，并且还与事务管理相关联，有着一定作用。
国际上处于主流地位的，那个被称作WebLogic的，以及同样处于主流地位的WebSphere，它们给予了强大无比的分布式事务方面的支持，然而呢，在那种轻量化以及国产化有着合规要求这样的情况下，名为东方通TongWeb的这个产品，展示出了它针对Java EE标准所进行的深度适配。
二、数据缓存中间件：Redis 协议兼容与缓存击穿解决方案
面对电商大促时出现的高并发流量状况，数据缓存成为保护后端数据库的首要防范屏障。第一道起着保护作用的防线上，是数据缓存针对电商大促高并发流量来保护后端数据库。
被国际上广泛认可主流的，那个名为Redis的东西，凭借着包含丰富数据结构的特点，像以Hash这种方式来存储对象，通过ZSet这种形式去实现排行榜，进而成为了事实标准。
像宝兰德BES Cache这样的国产替代方案，以及金蝶AMDC，都达成了100%对Redis协议的兼容性，其中金蝶AMDC做到了使其迁移成本极为低。因为这种兼容性，使得迁移成本很低。
于“秒杀”情形之下，我们借助 TongRDS 的分布式特质构建了二级缓存架构。
在代码这一层面，运用操作热点数据的 StringRedisTemplate，针对 key=“seckill:stock:1001” 来进行相关操作，并且要设定合理的 过期时间，比如说像时间达到 600 秒那样，与此同时还要开启 持久化 的机制，也就是 RDB/AOF 混合的那种，以此来确保缓存数据完全安全。
三、消息中间件：数据一致性保障与异步解耦
消息队列是保障分布式系统最终一致性的核心。
历经开源的、具备高吞吐特性的 Kafka，以及有着可靠性特点的 RabbitMQ，再到国产的东方通 TongLINK/Q，还有金蝶 ADMQ，进行选型之时，务必要紧密扣合业务。
针对事务消息去加以实现过程当中，我们精心设计出来了这样一种方案，也就是靠本地事务表再夹杂着定时任务扫描补偿的那种方案：其中业务操作这一块儿，像对Oracle订单表实施更新操作，它和朝着MQ发送half - message这个行为，是在同一本地事务范围之内给达成的。
要是Producer在中途出现崩溃的情况，借助定期去回查t_order_message表的状态，从而确认业务到底是commit还是rollback，这样就将消息丢失或者重复的情况给彻底避免掉了。
与此同时，运用 ADMQ 的 死信队列 也就是 DLQ 来处理那些经过多次重试之后依旧失败的消息，再结合 使用 ELK 进行监控告警，最终达成了无人值守状态下的可靠性保障。
四、服务代理中间件：读写分离与分库分表的路由策略
依托于 Nginx 或者它的国产替换品 东方通 TongHttpServer，我们不但使 HTTP 反向代理得以达成，而且还借助 lua-nginx-module 嵌入了自行定义的路由逻辑。
国产中间件已具备在生产环境承载核心业务的能力。
开展选型工作的关键要点在于，要能够深入且透彻地领会其对一种特定系统的支持情况，这种支持涵盖了像针对某一特定数据库的协议兼容性方面，比如对 MySQL 协议的兼容程度，还包括对另一特定数据库的语法适配度，像 Oracle 语法适配的状况，此外还有关于分布式事务的实现情况，并且还要把索引方面予以优化，以及连接池进行调优的相关经验，还有分库分表这些运维方面所积累的经验相结合，进而搭建起一个具备高可用性、高可靠性以及高性能的一种架构底座，也就是数据架构底座。
Comments NOTHING