作者简介：刘韬，在中间件领域有多年的实战经验，精通 WebLogic server，Websphere，Jboss，Tomcat，tuxedo，mq，osb等多种中间件技术，对中间件的故障处理、性能优化、升级迁移等需求积累了丰富经验。
对于分库分表来说，主要是面对以下问题： 选择一个数据库中间件，调研、学习、测试； 设计你的分库分表的一个方案，你要分成多少个库，每个库分成多少个表，比如 3 个库，每个库 4 个表； 基于选择好的数据库中间件，以及在测试环境建立好的分库分表的环境，然后测试一下能否正常进行分库分表的读写； 完成单库单表到分库分表的迁移，双写方案； 线上系统开始基于分库分表对外提供服务； 扩容了，扩容成 6 个库，每个库需要 12 个表，你怎么来增加更多库和表呢？ 这个是你必须面对的一个事儿，就是你已经弄好分库分表方案了，然后一堆库和表都建好了，基于分库分表中间件的代码开发啥的都好了，测试都 ok 了，数据能均匀分布到各个库和各个表里去，而且接着你还通过双写的方案咔嚓一下上了系统，已经直接基于分库分表方案在搞了。 那么现在问题来了，你现在这些库和表又支撑不住了，要继续扩容咋办？这个可能就是说你的每个库的容量又快满了，或者是你的表数据量又太大了，也可能是你每个库的写并发太高了，你得继续扩容。这都是玩儿分库分表线上必须经历的事儿。
现在很多并发性很高的系统为了提高吞吐量而使用redis来当数据存储，而当redis挂了的时候有可能数据丢失，这个时候系统可能不可用，而把流量路由到db肯定是不可行的，因为流量太大，这个时候恢复redis中的数据又比较耗时，而这个时候经常会出现使用多个reids集群，即有一个或者多个备份redis集群。这个时候怎么保证多个redis集群数据一致性呢？
参考博客1给出了一种所谓的平滑帅气的秒级扩容的架构方案，但我个人却认为，这个看似没有什么问题的方案在实际中几乎没什么用处，业界也几乎不会用这种方案来进行扩容（分库分表）。为了便于说明这一点，本文先简单回顾下该方案，然后分析该方案为什么没有用，最后给出三种业界广泛使用的分库分表的平滑扩容方案。
在今天双 11 这个万众狂欢的节日，对于阿里员工来说，每个环节都将面临前所未有的考验，特别是技术环节，今天我们就一起来探讨下双11天量交易额背后的技术。
作者简介 荣华，携程高级研发经理，专注于后端技术项目研发管理。 军威，携程软件技术专家，负责分布式缓存系统开发 & 存储架构迁移项目。 金永，携程资深软件工程师，专注于实时计算，数据分析工程。 俊强，携程高级后端开发工程师，拥有丰富SQLServer使用经验。 前言 携程酒店订单系统的存储设计从1999年收录第一单以来，已经完成了从单一SQLServer数据库到多IDC容灾、完成分库分表等多个阶段，在见证了大量业务奇迹的同时，也开始逐渐暴露出老骥伏枥的心有余而力不足之态。基于更高稳定性与高效成本控制而设计
基于公司内部开源共建原则， RocketMQ 项目只维护核心功能，且去除了所有其他运行时依赖，核心功能最 简化。每个 BU 的个性化需求都在 RocketMQ 项目之上进行深度定制。RocketMQ 向其他 BU 提供的仅仅是Jar 包，例如要定制一个 Broker，那么只需要依赖 rocketmq-broker 这个 jar 包即可，可通过 API 进行交互，如果定制 client，则依赖 rocketmq-client 这个 jar 包，对其提供的 api 进行再封装。
1.Provider提供方：服务提供者。2.Producer生产者：创建和发送JMS消息的客户端。3.Consumer消费者：接收JMS消息的客户端。4.Client客户端：生产或消费消息的应用&进程。5.Message消息：服务端与客户端之间的传输数据对象。6.Queue队列 ：包含待读取消息的准备区域（点对点）。7.Topic主题：发布消息的分布机制（发布&订阅）。
1、大型网站技术架构：核心原理与案例分析 本书通过梳理大型网站技术发展历程，剖析大型网站技术架构模式，深入讲述大型互联网架构设计的核心原理，并通过一组典型网站技术架构设计案例，为读者呈现一幅包括技术选型、架构设计、性能优化、Web安全、系统发布、运维监控等在内的大型网站开发全景视图。 本书作者李智慧，曾在阿里巴巴担任技术专家，参与阿里巴巴基础技术平台开发和架构设计。 2、分布式服务框架原理与实践 微服务是当前非常热的技术关键词之一，那么微服务如何落地呢？首先要实现服务化，微服务架构是一种服务化架构风
当系统访问量和数据量超过之前对评估预期时，涉及到对数据库重新分片。大部分场景中往往不能直接映射到新对数据分片策略中，分片策略修改需要伴随数据迁移。
Mysql优化那篇文章有朋友留言说就这么点？，深深刺痛了晓添的心，感觉知识深度被小看了，痛定思痛决定发布读写分离，分表分库优化文章，其实这系列文章也在Mysql优化的计划之内，最近较忙断断续续写的有点难受，到今天才跟大家见面，篇幅有限这篇我们来说说基于Mycat实现读写分离，话不多说我们赶紧看看好好的数据库又闹腾什么呢？
导语 由腾讯云中间件与Kong公司联合举办的线上技术直播将在12月21日晚上19：00进行，届时，对API网关感兴趣的开发者朋友们可以扫下方的二维码进入直播间观看。 关于网关 API 网关是现代分布式云原生，微服务系统中的一个重要组成部分。作为世界上最流行的开源网关之一，Kong 具备云原生、平台无关、可扩展的重要特点，以其通过插件实现的高性能和可扩展性而著称。Kong具备的核心能力包括请求/响应转换、负载均衡、健康检查、认证鉴权、流量治理、API管理等。 腾讯云原生网关 Kong 是腾讯云基于 Kong
相对于过去单体或 SOA 架构，建设微服务架构所依赖的组件发生了改变，因此分析与设计高可用容灾架构方案的思路也随之改变，本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。
关于Redis的其他的一些面试问题已经写过了，比如常见的缓存穿透、雪崩、击穿、热点的问题，但是还有一个比较麻烦的问题就是如何保证缓存一致性。
在这些可选项中，最常见的就是基于主从复制的方案，其次是基于Galera的方案，我们重点说说这两种方案。其余几种方案在生产上用的并不多，我们只简单说下。
本文整理了阿里13个开源中件间产品的架构及功能介绍，结合阿里中间件团队的访谈及分享，涵盖了消息中间件、服务框架、数据层、应用服务器和大规模分布式稳定性平台等等。整体中间件在阿里生态中的分布，如下图所示：
2022年，基于对稳定性的焦虑...和思考，交易平台联动中间件平台启动过异地多活项目的探索，虽然完成了核心应用及基础组件的改造，但在疫情&降本增效的影响下并未真正投产，同时也缺乏充分的测试以及线上流量的大规模验证；后续在不断的业务迭代中，相关设计及代码被冲击的面目全非，相关的多活自动化测试case也并没有沉淀下来。
我们都知道当今互联网发展特点就是快，我们作为研发所开发的任何产品，包括不限于APP、WEB端、WISE、H5等。本人经历过产品经理提出过要求研发team一个月开发一款新的APP上线，接下来就是避免重复造轮子似的“Ctrl+c&&Ctrl+v”,上线过后的代码运行阶段的稳定性结局可想而知。所以始终牢记一点，写常规代码的过程相对容易，但如何保证线上代码长期稳定的运行才是一个系统能否生存下去的关键，就好比开发一款产品是“0-1”的过程，类比于“婴儿”出生，成长的过程的稳定和恰到好处的高可用率是我们作为研发（“父母”）需要付出很多关心的地方。故而作为一名研发，当前系统在长期运行阶段，暴露许多数据资源不一致问题，这些问题有大有小，严重的影响波分快速扩容带宽需求的业务下发成功率，以及对Controller管控设备产生影响。并且对于整体波分系统的控制通道发生的设备托管问题较为频繁且严重，针对以上特点问题，天元平台项目启动。下文主要从项目概述、数据库、高并发架构、golang高级特性，以下都是我在开发过程中用到的一些经验和技术手段分享，没有最好的技术，只有合适的技术，因此也称不上是最佳实践，仅供参考。
也就是从 Greenwich.SR6, Hoxton.SR9 这样子的风格改为 2020.0.0。广大人民终于不用为spring cloud的版本号烦恼了。Spring Cloud推广不力，固然有自身复杂的原因，版本号太复杂也是一个坑。
一项技术的产生必然是为了解决问题而生，了解了一项技术解决的问题，就能够很轻松的理解这项技术的设计根本，从而更好地理解与使用这项技术。 消息中间件和RPC从根本上来说都是为了解决分布式系统的服务间通信问题，我们的服务从最初的单体应用发展到SOA架构到现在的微服务架构，必不可少的就是服务间通信，但从最初的设想，服务间通信仅仅就是一次请求响应调用而已，为什么发展出如此多的消息中间件与RPC技术，我们是否真的需要学习这么多的消息中间件技术？ 答案是肯定的，接下来我们将分析我们为什么要了解及使用如此多的服务间通信技术，以及他们究竟都解决了哪些问题，在什么场景下他们是必不可少的。
秒杀是电商业务里的标志性事件，这样的典型高并发场景会遇见什么样的挑战呢，然后又是如何来解决的呢? 秒杀活动场景 淘宝双11秒杀场景，大量的用户短时间内涌入，瞬间流量巨大（高并发），比如：1000万人同
导语 近几年，大型公有云故障引发的生产业务事故案例时有发生。由于很多开发者默认大型公有云的服务是一直可用的，在开发时没有针对公有云服务进行容错设计，在公有云故障时，就出现了业务的异常。可见，由于大型公有云实际上已经成为了全社会共同拥有的IT基础设施，其业务的高可用也已经成为了企业社会责任的一部分。腾讯云是如何通过完备的高可用设计，来保证云服务的业务连续性和数据持久性，从而承担大厂应有的社会责任的呢？ 这篇来自腾讯专有云的架构师方天戟的万字长文为您揭开腾讯专有云高可用设计的内幕。 一. IT 业务高可用的
这个你必须面对的事，就是当你已经弄好分库分表方案，测试也通过了，数据能均匀分布到各个库和表里去，而且接着你还通过双写方案上了系统，已经直接基于分库分表方案在搞了。
突然! 扩容了，扩容成6个库，每个库需要12个表，你怎么来增加更多库和表？ 当你已经弄好分库分表方案，测试也通过了，数据能均匀分布到各个库和表里去，而且接着你还通过双写方案上了系统，已经直接基于分库分表方案在搞了。 需求来了~现在这些库和表又支撑不住了，要继续扩容，咋办？
随着国际火车票业务的高速发展，订单量快速增长，单数据库瓶颈层面的问题逐渐显露，常规的数据库优化已无法达到期望的效果。同时，原先的底层数据库设计，也存在一些历史遗留问题，比如存在部分无用字段、表通过自增主键关联和各个应用直连数据库等问题。
如今随着互联网的发展，数据的量级也是成指数的增长，从 GB 到 TB 到 PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求。这个时候 NoSQL 的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。
2021年7月30~31日（本周六），GIAC 全球互联网架构大会将于深圳华侨城洲际酒店盛大开启！ GIAC全球互联网架构大会是由 msup 和高可用架构技术社区联合举办的面向架构师、技术负责人及高端技术从业人员的技术架构大会。 作为业内技术领先的云服务商，腾讯云高级解决方案架构师邱浩受邀参会，为数千名技术负责人、架构师和高级研发人员带来关于基础架构方面的最新技术实践。 ■ 满满干货，开启架构新思路 国内多数电商平台，在业务发展初期，其平台均部署在单个数据中心，平台发展到一定规模后，一旦单个数据中心故
昨天躺在床上刷知乎，看见一个问题：“中国有哪些顶级水平的程序员？” 引起了我的注意，看了下现在已经超千万浏览了。 其实谈起中国顶尖的程序员，大多数人首先会想到之前的雷军雷布斯，微信的张小龙，还有现在的多隆、行癫、道哥等人，但今天我想聊一聊的这位大神，他的技术成就也同样令人瞩目。 19 年获得国家技术发明二等奖、20 年获得国家计算机协会颁发的“ CCF 杰出工程师奖”，曾带领淘宝完成了由 3.0 向 4.0 的电商架构的升级，江湖人称“毕大师”，他就是前阿里 P10 ——毕玄。 说毕大师是我佩服的 t
在我们日常开发中,我们存储数据的方式一般都在数据库中,一般业务系统不会存在高并发的情况,也不怎么可能会发生概率性BUG问题,可一旦发涉及了高并发的需求,例如现在年底抢火车票的情景,单一使用数据库来保存数据肯定是不行的,首先我们的DB数据库是面向磁盘的,服务端与数据库交互都会有磁盘读/写操作而且该方式效率以及性能比较慢。
随着系统访问量的提高，复杂度的提升，响应性能成为一个重点的关注点。而缓存的使用成为一个重点。redis 作为缓存中间件的一个佼佼者，成为了面试必问项目。本文分享一下Redis几道常见的面试题：
恭喜你，贵公司终于成长到一定规模，需要考虑高可用，甚至分库分表了。但你是否知道分库分表需要哪些要素？拆分过程是复杂的，提前计划，不要等真正开工，各种意外的工作接踵而至，以至失控。
今天抽空整理，发现近期问我数据恢复，灾备的问题还比较多，我简单整理了一下。 问题1： 能请教一个问题么？我们用was链接的oracle数据库，是不是不建议在was上设置statementcachesize的参数？我们目前设置的是200，发现数据库中那个session都会持有200个游标，有工程师建议把这个参数设置为0 这个问题着实还问到我了，不过我问了下专业的中间件工程师，答复如下： Statement Cache Size是指有多少个prepared statement或者callable state
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
不去评论作者的能力，对于新手来说，我觉得这本书是对于大型网站后台建设思路的扫盲书，很值得小白一读。
京东的内容创作平台有很多的样式，比如文章、单品推荐、搭配、店铺上新、秒杀、直播预告、优惠卷。有些样式可以投稿到不同的频道，频道就好比露出的位置，频道露出的前提是内容质量审核通过后，频道侧二审通过。上面列举的有些样式因为时效性的考虑所以是不需要审核就可以外露的，比如直播预告、优惠卷，其他的样式则需要在CMS后台管理中经过一道或者两道审核，或者在质检抽查中复活。
昨天我们讲解了数据库分库分表后我们怎么去生成主键唯一ID（数据库分库分表后，我们怎么保证ID全局唯一），到目前为止我们已经掌握分库分表的策略了也会搭建统一发号器进行生成唯一ID。
伴随着互联网行业的发展，金蝶和用友分别都有可部署在云端的产品，如K3cloud与U8等。企业本身也变得越来越轻，原先动辄几万甚至几十万的机房部署与人工管理，是现代化企业所不能接受的，在残酷的生存环境下，他们需要更轻的模式和更经济的方案。随着公有云市场的逐渐繁荣，越来越多的企业开始进行云上的实践，ERP系统在云端的部署，也逐渐形成一种新的业务模式，节省了企业建设机房与昂贵的固定人工成本。将机器托管在云端，由专业的云厂商来管理、运维基础设施，无需太多的考虑扩展和冗余的问题，大幅度降低系统部署的支出，而转为按需付费，是企业所乐意接受的。
最近大连车务段在其公众号发表了题为《全力攻关一昼夜，确保运输三十站》的文章，迅速在网络上引发了群嘲，面对舆论压力只好自行删除了此文。起因是其现在车子系统在浏览器中运行的网页代码依赖Flash Player控件的运行，而其开发商Adobe公司呢，完全没考虑商用业务系统的风险做了一个骚操作，在32后的版本中加入了“定时炸弹”，从2021年1月12日(美国时间)开始禁止Flash内容在Flash Player中运行，而Flash Player在Windows 8及以上版本的操作系统中一直是内置自动更新的，从而引发了现在车子系统的故障。按理说你Adobe公司不再维护Flash Player也就罢了，用户继续使用引发的风险自己承担，也没人会来追究你的责任，非要整这么一个定时炸弹在软件中，这和植入了木马病毒又有啥差别呢？可能很多人在说，3年前Adobe公司就公告了这个时间点会停止更新和分发Flash Player，相信大家也绝不会想到Adobe公司会植入这个定时炸弹。而大连车务段遇到的问题绝不是孤例，只是并非所有单位都在公众号发个表扬稿罢了。
作者 | 汪成坤 策划 | 褚杏娟 在泛敏捷思潮变革、DevOps 大行其道的背景下，小步快跑的模式极大程度压缩了质量保障活动的时间，传统的自动化测试工具已无法满足持续交付的需求。流量录制回放的概念近年来愈发火热，从业界大会到社区论坛，众多工程师进行了大量的思辩悟，肯定了 API 录制回放能有效地解决测试、研发工程师在质量活动中的核心痛点从而带来可观测的研发效能提升。 流量录制回放的核心价值是通过直接录制生产的高保真数据，快速地在测试环境中进行回放比对接口返回值和中间链路的验证。录制回放很热，行业
在软件开发领域，异地多活是分布式系统架构设计的一座高峰，很多人经常听到过他，但很少人理解其中的原理;
只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？
从今年7月到现在转眼间转岗到淘宝部门已经有小半年了，最近刚刚经历人生中第一次双11实战，体验了一把系统经受高并发高流量的冲击的感觉，一个字爽，作为小白，在这小半年里面收获颇多，一个感悟是实战是提高一个人能力的唯一真理，只有真的动手去做了，才会知道会遇到什么问题。日常做项目时候不怕遇到问题如何解决，最怕有些情景考虑不到，而后者是需要经验累积起来的，一方面是试错的累积，一方面是通过书本或者思考源码得来的。来淘宝这半年来为了能够学到更多，从来不敢浪费时间，一边欣赏这人家如何用代码解决高并发高流量问题，一边学着人家如何用工具快速高效的查询系统瓶颈与查找线上问题。
背景 我们开发一般的企业级Web应用，其实从本质上来说，都是对数据的增删查改进行各个维度的包装。所以说，不管你的程序如何开发，基本上，都离不开数据本身。那么，在开发企业级应用的过程中，很多同学一定遇到过这样的困惑，当完成了应用程序的基本增删查改功能之后，用户会经常吐槽当下的查询功能并不能满足自己的查询需求。这是因为，通常情况下，我们基于传统的数据库进行开发，都是需要预先去进行各种方面的考虑，然后再开发相应的查询语句。与其说是查询语句，不如说是数据过滤语句。这种时候，一个全能的搜索引擎就非常有必要了，通常我们
做多活比较难搞的是中间件的多活和有状态服务的数据同步。zk作为一般公司的服务发现的方案，其多机房集群的搞法也是一个问题。
导语 由InfoQ主办的DIVE全球基础软件创新大会，将于4月15-16日线上举办。 关于DIVE 深入基础软件，打造新型数字底座 InfoQ 的使命是让创新技术推动社会进步。所以，基础软件及开源领域将始终是 InfoQ 的重点关注及报道的领域。本次大会分两天进行，60+专家倾心打造，涵盖数据库、开源、操作系统、编程语言、中间件、微服务等十余场专题演讲，希望成为基础软件领域内容最丰富、最前沿、最具技术性的行业大会，成为基础软件领域的风向标，许多标杆企业发布重要趋势性更新的首选舞台；并为行业领导人物、学者、
本文由公众号“水滴与银弹”号主Kaito原创分享，原题“搞懂异地多活，看这篇就够了”，为使文章更好理解，有修订。
ROS具有很强的代码可复用性和硬件抽象性能，采用分布式架构，通过各功能独立的节点实现消息传递任务的分层次运行，从而减轻实时计算的压力。同时ROS为常用的机器人和传感器提供了硬件驱动接口。
在互联网的业务系统中，涉及到各种各样的ID，如在支付系统中就会有支付ID、退款ID等。那一般生成ID都有哪些解决方案呢？特别是在复杂的分布式系统业务场景中，我们应该采用哪种适合自己的解决方案是十分重要的。下面我们一一来列举一下，不一定全部适合，这些解决方案仅供你参考，或许对你有用。 一个ID一般来说有下面几种要素： 唯一性：确保生成的ID是全网唯一的。 有序递增性：确保生成的ID是对于某个用户或者业务是按一定的数字有序递增的。 高可用性：确保任何时候都能正确的生成ID。 带时间：ID里面包含时间，一眼扫
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
