故事
道光年间，景德镇有个烧御瓷的官窑，每年要出十万件青花供宫廷采办。窑厂分作东西两区，每区五十座窑，一窑一火，各烧各的。按老规矩，同一批贡品必须集中在同一区——东区的瓷送养心殿，西区的瓷送慈宁宫，泾渭分明。
这一年夏天，东区第三十七座窑出了事。装坯的匣钵受潮，一窑青花全裂了冰裂纹，成了废品。更要命的是，这批刚好是养心殿端午宴要用的五百件龙舟碗。总管太监催得急，窑厂大监只好把东区所有窑都腾出来补烧，东区的其它贡品全耽误了。慈宁宫那边倒没事——西区照烧不误。
大监姓周，是内务府派下来的，在景德镇蹲了十五年。他看着东区乱成一团的调度，想了一个问题：为什么一窑出事，要连累整整半个厂？
他翻旧档，发现这规矩是乾隆朝定的。那时窑小，一窑也就出几十件，集中管理方便对账。如今一窑能出千件，五十座窑就是五万件，半个厂一耽误，数字大得吓人。周大监想改，可怎么改？若把同一批贡品拆散到东西两区，烧坏了还能从另一区调；可拆得太碎，调度、对账、追责全是麻烦。
他琢磨了三个月，定出一套新法。
—
周大监把全厂一百座窑编了号，从一到一百。每年贡品不再按"这批归东区、那批归西区"来分，而是每批贡品随机抽七座窑。抽法有讲究：用贡品单上的"批号"当种子，算出一组固定的窑号，这批货一辈子就认这七座。同一批的龙舟碗、碟、勺、壶，全进这七座窑；换一批贡品，换一组窑号。
他管这叫碎杯法——把整桌的杯子打碎重排，每只杯子只装一小口酒，翻了一只，洒不了整桌。
这法子的好处，周大监跟老窑工解释过。以前东区五十座窑是一大片，一窑坏了，同区的货全受影响。现在每批货只占七座，七座里坏一窑，还有六窑能兜底。更妙的是，两批货撞进同一座窑的概率极低——批号随机，七座窑的组合有上亿种，想故意撞上都难。
老窑工不懂概率，但懂火候。他们问：调度怎么办？以前东区的货去东区拉就行，现在每批货的七座窑散在全厂，烧成了得满厂跑着收。周大监说：这就是代价。用调度的麻烦，换不翻桌的保险。
—
碎杯法跑了两年，没出大事。直到道光二十三年，一场怪雨打湿了西区十几座窑的柴堆，连着三天烧不出正色。按老规矩，西区五十座窑全废，慈宁宫的冬供要断档。可按碎杯法，每批货的七座窑散在全厂，西区湿的十几座窑，摊到各批里每批顶多湿一两座——那批货还有另外五六座窑撑着。全厂一百批货，没有一批全军覆没。
周大监站在雨里，看着窑工从干柴的窑里抢出青花，忽然明白碎杯法的真正价值不在"不坏"，而在坏得有节制。以前是一区坏、半桌翻；现在是几座窑坏、几口酒洒。损伤从"大片"变成"碎点"，从"能被人看见"变成"混在整桌里数不出来"。
但老问题还在：调度太碎。每批货七座窑，一百批就是七百个"窑-批"对账点，库房管事骂了三年。周大监又改了一版：不是每批抽七座，而是先把一百座窑分成二十组，每组五座；每批随机抽三组，共十五座。组内固定，组间随机。调度时按组走，对账点从七百降到六十，碎的程度减了，保险的程度还在。
后来的人把这叫分层碎杯——底层单元固定成组，上层随机组合。组是"硬边界"，保调度效率；随机是"软隔离"，保爆炸半径。
—
碎杯法在景德镇没传太久。咸丰年兵乱，官窑散了，规矩跟着人走，进了洋人的工厂管理书，又进了后来那些机房的运维手册。名字也换了几轮：先叫"随机分舱"，后来洋人译成 Shuffle Sharding，意思是"洗牌式的分片"。
如今的机房里没有窑，有的是服务器、机柜、可用区。道理却一模一样：把用户随机撒进无数小单元，让每个用户只占一小撮资源，一撮坏了，用户顶多慢几秒，不会全黑。AWS 的 Route 53、S3、Lambda，底层都有这层碎杯结构——不是为了让系统不坏，而是为了让系统坏得有体面。
周大监若活到今天，大概会认得出那些机房的架构图：一百座窑变成几千个单元，批号变成用户 ID，随机算法从抓阄变成哈希。核心没变——用组合的随机性，换故障的局部性。调度麻烦？当然麻烦。可比起半桌翻掉的场面，满厂跑着收瓷算轻的了。
概念解析
Shuffle Sharding 是 Amazon AWS 推广的一种故障隔离技术。传统分片把用户按固定规则分到若干大 shard，一个 shard 故障影响其全部用户。Shuffle Sharding 则让每个用户被随机分配到一组 micro-shard（单元组合），组合空间极大，两个用户共享完全同一组单元的概率极低。
当故障击中某个单元时，传统分片下该 shard 的全部用户受损；Shuffle Sharding 下，只有那些"恰好抽到这个单元"的用户受影响——按概率摊薄到近乎可以忽略的比例。AWS 的实践表明，这种随机分配能把大规模故障的影响面压缩到 1/7000 甚至更低。
工程实现上，Shuffle Sharding 常与 Cell-based 架构配合：底层 Cell 是固定资源池，上层用确定性随机（如基于用户 ID 的哈希）把用户映射到 Cell 组合。这样既保留了随机隔离的保险，又避免了完全无规律的调度灾难——用户的单元组合虽随机，但是固定的，缓存、路由、监控都能围绕这个固定映射来建。
核心取舍在于：用调度的复杂度，换故障的局部性。当系统大到"任何单元都可能坏"时，Shuffle Sharding 把"谁坏"的不可预测，转化为"坏多少"的可预测——从"可能翻半桌"变成"顶多洒几口酒"。