中班数学题连线，幼儿园的数学连线题

1，幼儿园的数学连线题

目测应该连接两条线。一条全是昆虫，连12345 一条全是天象，连12345

幼儿园的数学连线题

2，幼儿园的题目怎么连

你好你可以根据动物的颜色跟气球的颜色来连线颜色相同的连一块就好了

呵呵你想多了！就是把一大一小连给每个小动物就可以了！

每位头顶都对应好了两个气球，连在高举的手里

幼儿园出题有问题吗？还是他们想要孩子从字面上回答，把17分成10和7，就是7和7相同？我认为这可能是题目出错了。如果不是出错题，就是思路错了，这是把简单的问题复杂化，把孩子和家长都教的一头雾水。

用笔从气球的绳连线到小动物的手上每人2个气球

幼儿园的题目怎么连

3，帮我找一些关于小班的一些数学题比如看图写数字连线图看数字

1，看图写数。☆☆☆☆☆☆☆= ★★★★★= ☆☆☆=☆☆☆☆☆☆= ★★= ☆☆☆☆☆☆=2，连线7-2= 9 9-3= 2 5+4= 6 8-6= 89-2= 5 5+3= 6 3，看数字图星。3 ☆☆☆☆☆☆5 ☆☆☆☆☆☆8 ☆☆☆☆☆☆☆☆☆☆9 ☆☆☆☆☆☆☆☆☆☆

你好！1+1 4 1+0 23+1 1如有疑问，请追问。

1+1 4 1+0 23+1 1

帮我找一些关于小班的一些数学题比如看图写数字连线图看数字

4，小班五领域数学看图连线教案怎样写

活动目标： 1、学习按物品的多少画出相应数量的竖线。 2、能根据物品的数量找出对应关系，会比较物体数量的多少。活动准备： 1、上面画有实物、下面可以画竖线的记录表1张。 2、操作材料若干，彩笔若干，可以画线的记录纸若干（物品的数量在5以内）。 3、教学挂图《小老鼠吃蛋糕》。活动过程：一、分一分 1、幼儿自由选择数量、颜色或形状不同的操作材料，然后将材料按某种特征分类。 2、引导幼儿说出分类后每种物品的数量。 3、思考：用什么样的记录方式统计物品的数量？二、画竖线记录数量 1、教师出示记录表，并示范讲解，根据星星的数量在下面空格里画出相等的竖线。 2、幼儿自由选择记录表，然后根据表中物品的数量画出相等数量的竖线。 3、鼓励幼儿根据竖线的多少分别说出物品的数量。三、观察画册《看图连线》 1、说一说，乐乐和奇奇收到了哪些礼物？哪些礼物多？哪些礼物少？ 2、数一数，每种礼物各有多少个？ 3、连一连，将数量相同的礼物连起来。

5，问数学题要解题过程

1.设每筐x千克。 3/8(12X+36)=4X+36 X=45 45*12+36=216kg 2.设6（2）班有x人。 x-8=(4/5+8)*7/8 x=50 4/5*50+50=90人 3.设甲的速度为xm/h,乙为ym/h. 7x=7y+7 7x=4(x+y) 解的 x=4 y=3 4*7=28千米 4.设大量筒容量为x，小的为y. 15x=20y x=4/3y 设大.小共用K次能装满则(4/3y+y)k=20y k=60/7 所以大量筒倒了9次，最后一次为大量筒 5.上面右边圆的圆心和下边左边两个圆的交点的连线在这里写数学还真有点不习惯啊

第一题：设每筐x千克，则：（4x+36）/8x=3/5 解出x=45 然后总产量就是12x+36=576 第二题：设六（2）班有x人（x-8）/（4x/5+8）+7/8 第三题：设甲每小时走x千米，乙每小时y千米，AB两地相距z千米，则：方程一：4（x+y）=z 方程二：7x=z 方程三：7y+7=z 解三元一次方程组得z=28千米第四题：大杯一次到1/15，小杯一次到1/20，所以大小杯相加一个循环一共是7/60，然后1除以7/60，取整为8，余下1/15，正好一大杯，所以大杯一共9杯，最后一杯是大杯到的第五题：要图片来找我

6，幼儿园中班数学活动教案哪条路最长

1．不受物体排列形式的影响，探索比较路线长短的方法，正确判断路线的长短。2．在操作活动中学习观察和比较的方法，发现错误能及时纠正。准备：数字印章，印泥，记录单，用四种不同颜色不同数量拼插玩具各自拼搭而成的路线模型。过程：一、引出话题师：小班的弟弟妹妹想找一条最长的路线进行跑步比赛可是你们眼前的几条路线都是弯弯曲曲的，哪条路线是最长的呢？他们犯难了。小朋友，你们能帮他们找出这条最长路线吗？二、比较路线的长短1.出示路线模型，引导幼儿观察。2．引导幼儿说出各自的想法及判断的理由，并针对不同的回答给予适当的引导。在交流的过程中，教师要根据幼儿不同的反应给予不同的引导。例如对于那些反应迅速、已经找到正确方法的幼儿，教师可暂时不作任何评价，而是鼓励幼儿通过动手操作来验证自己的想法。对于那些面有难色、一时想不出办法的幼儿，教师要给予适当的指导。如，通过语言启发：“玩具身上的小孔能不能帮帮我们呢？”以帮助他们找到解决问题的方法。三、幼儿操作活动1．说明要求。师：每组都有四个用不同颜色不同数量的拼插玩具各自拼搭起来的路线模型，请小朋友按照记录单上的线段颜色，找到相应的路线模型，并比较它们的长短，把判断结果标记在与颜色对应的记录单上。2．幼儿操作，教师观察幼儿比较长短的方法，适当帮助有困难的幼儿。四、活动评价1．展示幼儿记录单，引导幼儿观察。2．引导幼儿集体验证。在验证的过程中，教师除了引导幼儿用点数玩具数量的方法比较路线的长短外，还可引导幼儿将玩具排直后直接比较，从而进一步验证运用数量多少比较出来的结果是否正确。3．提升与总结。教师以弟弟妹妹的口吻向幼儿请教，一方面可以做到首尾呼应，激发幼儿的责任感和自豪感，另一方面也可帮助幼儿总结经验，回顾与梳理活动的过程。反思：二、材料选择的原则在数学活动中，材料选择的恰当与否往往会影响甚至决定整个教学活动的成败。一般来说，幼儿是通过操作活动材料获得相关经验的。因此，如果教师提供的活动材料能有效暴露幼儿某些认识的误区，又能在最后帮助幼儿获得正确认识，那么，这样的材料就能为教学活动的有效开展提供有力的保障。因此，在设计该活动时，我选择了幼儿园最常见的拼插玩具，它是一个个的正方体，每个正方体都能拼插连接起来。这一玩具的基本特点是，它既可以组合成直线，也可以组合成曲线。幼儿可以借助点数正方体的数量，比较发现用这种玩具拼搭出来的路线模型的长短。此外，由于这一玩具可以随意组合拼插，幼儿也可以将它们拼插成直线，通过直接的比较方法，凭直观分辨出长短来。三、环节设计的思路环节的设计应围绕教学目标，由浅入深，逐步展开，以引导幼儿向着正确的方向前进。就该活动而言，教师应首先了解幼儿的一般认识，即：面对四条弯曲不同的路线，他们是如何判断其长短的。其次，针对幼儿认识上的误区提出问题，引导幼儿讨论交流，确定判断的标准。第三，让幼儿通过操作验证自己的判断，以获得正确的认识和经验。四、活动过程的指导当我展示出由幼儿熟悉的玩具拼搭出的路线模型时，幼儿的积极性一下子被有效地激发出来了。面对四条弯曲程度不同的路线，幼儿在评判哪条路线最长的问题上产生了诸多分歧，并激烈地争论起来。面对这样的热闹场面，我并没有急于作出什么结论，而是引导幼儿讨论和动手验证，找到用点数玩具数量的方法比较路线长短的有效办法。在交流的环节，我又继续引导幼儿运用拉直比较的方法，找出最长的路线。通过这个过程，幼儿最终形成了这样的认识：比较路线的长短，不能只凭眼睛看，而要通过数一数、摆一摆等实际操作的办法来验证，以找到正确答案。（东南大学幼儿园吴岚）

【活动目标】 1、探索同样的东西根据不同的特征可以排出不同的结果。 2、在数学排序活动中体验创造性思维活动的乐趣。【活动准备】白板课件一份、幼儿操作材料人手一份。【活动过程】一、谈话导入。今天，老师给小朋友请来了几位小客人，它们就藏在这里，我们一起把它们找出来吧。二、根据动物的某一特征进行排序。 1、（课件：四只小猴）师：是谁呀？一起跟小猴子们打个招呼吧。（小猴子，你们好！）看看有几只猴子呀？ 2、我们来看着这四只猴子长的一样吗？ 3、（课件：声音）它们和你们一样都有好听的名字，想不想知道它们叫什么呢？那我们一起来问一问？（小猴小猴，你叫什么呀？我长得高，我叫高高。）它叫什么呀？（高高）那猜猜看这只猴子叫什么？一起问问它吧。（小猴小猴，你叫什么呀？我长得胖，我叫胖胖）还有两只小猴也迫不及待地想要介绍自己，仔细听……（播放录音） 4、原来他们一个叫高高、一个叫胖胖、一个叫长尾巴、还有一个叫大脚。它们经常聚在一起玩，今天它们又一起来到了森林里。突然，它们看到了一根好香好大的香蕉，它们都非常想吃。 5、提问：这可怎么办呀？大家就想了一个（jy135幼儿教育 www.jy135.com）办法，比赛呗，比赛最公平了，谁得第一，谁就第一个吃香蕉。你们觉得这个办法好不好？ 6、（课件：胖胖）四只猴子中间啊有一只猴子，它的脑袋转得最快，（点击出现猴子胖胖）你们还认识它吗？嗯，胖胖想：在四只猴子中间我是最胖的，等一下我要和它们比胖，我准能拿第一，我就能吃到香蕉了。于是胖胖就说：“我们比胖吧。” 7、大伙都同意了，于是胖胖就带着它的三个好朋友一起来到大树下，那比的时候要注意什么呢？（要排好队伍，要站在一条线上） 8、（课件：胖胖、长尾巴、高高、大脚）于是胖胖就带着它的三个好朋友从胖到瘦排好了队伍。看看，它们的比赛结果怎么样？谁比胖胖瘦一点，对长尾巴排第二。排在第三的是谁？恩，是高高。大脚比高高瘦一点所以排在最后。 9、（课件：声音）看来比赛结果很明显，胖胖得意极了它说：瞧吧，瞧吧，我得了第一，我能第一个吃到香蕉啦。 10、（课件：声音）唉唉唉，不行不行，我也能吃到香蕉。提问：哎呀，谁在说话呢？（点击课件）这是谁？（高高）高高说：如果是这样的话我也能比，我也能第一个吃到香蕉。 11、提问：哎，小朋友你们觉得高高和猴子们比什么能得第一呢？ 12、嗯，你真聪明。高高说我们比身高吧，谁最高，谁就第一个吃香蕉。谁愿意来帮帮他们比一比？注意哦，排队的时候要排得整齐一点，要踩在同一条线上。（高高、大脚、胖胖、长尾巴）高高是第一个，它是最高的。谁比高高矮一点（大脚），它排第几啊？（第二）比长尾巴再瘦一点，排第三的是谁呢？（胖胖）长尾巴是四只猴子中最矮的，它比胖胖还要矮一点，所以只能排最后，看来这一轮比赛谁第一名啊？（高高）高高说：嘿嘿，那我就先吃香蕉呗。 13、（课件：声音）不行不行，我们两个等会儿比赛也能拿第一，也能吃到香蕉。这句话是谁说的？我们一起来看看，原来是长尾巴和大脚在说。哎，小朋友那你们觉得长尾巴和大脚比赛的话比什么呢？长尾巴比什么？同意吗？大脚要比什么呢？大脚说：我们来比脚吧，谁的脚大谁就先吃香蕉。 14、交代操作要求：比赛到这里真是越来越激烈了，你们愿不愿意帮帮它们？老师这里呀给你们每人准备了一块板，上面有四只小猴子，请你们一起来帮帮长尾巴和大脚。那老师先来考考你们哦，如果长尾巴比赛，它排在哪儿？记住哦，从小红旗这边开始排。它们等不及了快去帮帮它们吧。三、评价、分享香蕉。 1、师：小朋友这些小猴子都排好了整齐的队伍，我们一起来看看它们排得对不对？嗯，你们真得很棒，一起来表扬一下自己。 2、原来这四只小猴根据自己身上不同的特点来比赛它们都能够得第一。那这又香又甜的香蕉可怎么办呢？（分享着吃，一人吃一口，好东西要和好朋友一起分享） 3、哎，四只猴子都有自己的特点，最后他们发现好东西可以分享着一起吃。

7，不就是一个订票网站吗12306的核心模型设计思路究竟复杂在哪儿

12306这个系统，核心要解决的问题是网上售票。涉及到2个角色使用该系统：用户、铁道部。用户的核心诉求是查询余票、购票；铁道部的核心诉求是售票。购票和售票其实是一个场景，对用户来说是购票，对铁道部来说是售票。因此，我们要设计一个在线的网站系统，解决用户的查询余票、购票，以及铁道部的售票这3个核心诉求。看起来，这3个场景都是围绕火车票展开的。查询余票：用户输入出发地、目的地、出发日三个条件，查询可能存在的车次，用户可以看到每个车次经过的站点名称，以及每种座位的余票数量。购票：购票分为订票和付款两个阶段，本文重点分析订票的模型设计和实现思路。其实还有很多其他的需求，比如给不同的车次设定销售座位数配额，以及不同的区段设置不同的限额。但相比前面两个需求来说，我觉得这个需求相对次要一些。需求分析确实，12306也是一个电商系统，而且看起来商品就是票了。因为如果把一张票看成是一个商品，那购票就类似于购买商品，然后每张票都有库存，商品也有库存的概念。但是如果我们仔细想想，会发现12306要复杂很多，因为我们无法预先确定好所有的票，如果非要确定，那只能通过穷举法了。我们以北京西到深圳北的G71车次高铁为例（这里只考虑南下的方向，不考虑深圳北到北京西的，那是另外一个车次，叫G72），它有17个站（北京西是01号站，深圳北是17号站），3种座位（商务、一等、二等）。表面看起来，这不就是3个商品吗？G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员（包括某些中等规模公司的专家、CTO）就是在这里栽第一个跟头的。实际上，G71有136*3=408种商品（408个 SKU），怎么算来的？如下：如果卖北京西始发的，有16种卖法（因为后面有16个站），北京西到：保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商品，同理，石家庄上车的，有15种下车的可能，以此类推，单以上下车的站来计算，有136种票：16+15+14….+2+1=136。每种票都有3种座位，一共是408个商品。为了方便后面的讨论，我们先明确一下票是什么？一张票的核心信息包括：出发时间、出发地、目的地、车次、座位号。持有票的人就拥有了一个凭证，该凭证表示持有它的人可以坐某个车次的某个座位号，从某地到某地。所以，一张票，对用户来说是一个凭证，对铁道部来说是一个承诺；那对系统来说是什么呢？不知道。这就是我们要分析业务，领域建模的原因，我们再继续思考吧。明白了票的核心信息后，我们再看看G71这个车次的高铁，可以卖多少张票？讨论前先说明一下，一辆火车的物理座位数（站票也可以看成是一种座位，因为站票也有数量配额）不等于可用的最大配合。所有的物理座位不可能都通过 12306网站来销售，而是只会销售一部分，比如40%。其余的还是会通过线下的方式销售。不仅如此，可能有些站点上车的人会比较多，有些比较少，所以我们还会给不同的区间配置不同的限额。比如D31 北京南至上海共有765张，北京南有260张，杨柳青有80张，泰安有76张。如果杨柳青的80张票售完就会显示无票，就算其他站有票也会显示无票的。每个车次肯定会有各种座位的配额和限额的配置的，这种配置我目前无法预料，但我已经把这些规则都封装近车次聚合根里了，所有的配置策略都是基于座位类型、站点、区间配置的。关于票的配置抽象出来，我觉得主要有3种：1）某个区段最多允许出多少张；2）某个区段最少允许出多少张；3）某个站点上车的最多多少张；当用户订票时，把用户指定的区段和这3种配置条件进行比较，3个条件都满足，则可以出票。不满足，则认为无票了。下面举个例子：ABCDEFG，这是所有站点。座位总配额是100，假设B站点上车，E站下车的人比较少，那我们就可以设定BE这个区段最多只能出10张票。所以，只要是用户的订票是在这个区段内的，就最多出10张。再比如，一列车次，总共100个座位配额，希望全程票最少满足80张，那我们只要给AG这个区段设定最少80张。那任何订票请求，如果是子区间的，就不能超过100-80，即20张。这两种条件必须同时满足，才允许出票。但是，不管如何做配额和限额，我们总是针对某个车次进行配置，这些配置只是车次内部售票时的一些额外的判断条件（业务规则），不影响车次模型的核心地位和对外暴露的功能。所以，为了本文讨论的清楚起见，我后续的讨论都不涉及配额和限额的问题，而是认为任何区段都可以享受火车最大的物理座位数。并且，为了讨论问题方便，我们减少一些站点来讨论。假设某个车次有A,B,C,D四个站点。那001这个人购买了A,B这个区间，系统会分配给 001一个座位x；但是因为001坐到B站点后会下车，所以相当于x这个座位又空出来了，也就是说，从B站点开始，系统又可以认为x这个座位是可用的。所以，我们得出结论：同一个座位，其实可以同时出售AB,BC这两张票。通过这个简单的分析，我们知道，一列火车虽然只有有限的座位数，比如1000个座位。但可以卖出的票远远不止1000个。还是以A,B,C,D四个站点为例，假如火车总共有1000个座位，那AB可以卖1000张，BC也可以卖 1000张，同样，CD也可以卖1000张。也就是说，理论上最多可以卖出3000张票。但是如果换一种卖法，所有人都是买ABCD的票，也就是说所有的票都是经过所有站点的，那就是最多只能卖出1000张票了。而实际的场景，一定是介于1000到3000之间。然后实际的G71这个车次，有17个站，那到底可以卖出多少个票，大家应该可以算了吧。理论上这17个站中的任意两个站点之间所形成的线段，都可以出售为一张票。我数学不好，算不太清楚，麻烦有数学好的人帮我算算，呵呵。通过上面的分析，我们知道一张票的本质是某个车次的某一段区间（一条线段），这个区间包含了若干个站点。然后我们还发现，只要区间不重叠，那座位就不会发生竞争，可以被回收利用，也就是说，可以同时预先出售。另外，经过更深入的分析，我们还发现区间有4种关系：1）不重叠；2）部分重叠；3）完全重叠；4）覆盖；不重叠的情况我们已经讨论过了，而覆盖也是重叠的一种。所以我们发现如果重叠，比如有两个区间发生重叠，那重叠部分的区间（可能夸一个或多个站点）是在争抢座位的。因为假设一列火车有100个座位，那每个原子区间（两个相邻站点的连线），最多允许重叠99次。所以，经过上面的分析，我们知道了一个车次能够出售一张车票的核心业务规则是什么？就是：这张车票所包含的每个原子区间的重叠次数加1都不能超过车次的总座位数，实际上重叠次数+1也可以理解为线段的厚度。模型设计上面我分析了一下票的本质是什么。那接下来我们再来看看怎么设计模型，来快速实现购票的需求，重点是怎么设计商品聚合以及减库存的逻辑。传统电商的思路如果按照普通电商的思路，把票（站点区间）设计为商品（聚合根），然后为票设计库存数量。我个人觉得是很糟糕的。因为一方面这种聚合根非常多（上面的G71就有408个）；另一方面，即便枚举出来了，一次购票也一定会影响非常多其他聚合根的库存数量（只要被部分或全部重叠的区间都受影响）。这样的一次订单处理的复杂度是难以评估的。而且这么多聚合根的更新要在一个事务里，这不是为难数据库吗？而且，这种设计必然带来大量的事务的并发冲突，很可能导致数据库死锁。总之，我认为这种是典型的由于领域模型的设计错误，导致并发冲突高、数据持久化落地困难。或者如果要解决并发问题，只能排队单线程处理，但是仍然解决不了要在一个事务里修改大量聚合根的尴尬局面。听说12306是采用了Pivotal Gemfire这种高大上的内存数据库，我对这个不太了解。我不可想象要是不使用内存数据库，他们要怎么实现车次内的票之间的数据强一致性（就是保证所有出售的票都是符合上面讨论的业务规则的）？所以，这种设计，我个人认为是思维定势了，把火车票看成是普通电商的商品来看待。所以，我们有时做设计又要依赖于经验，又要不能被以往经验所束缚，真的不容易，关键还是要根据具体的业务场景多多深入分析，尽量分析抽象出问题的本质出来，这样才能对症下药。那是否有其他的设计思路呢？我的思路聚合设计通过上面的分析我们知道，其实任何一次购票都是针对某个车次的，我认为车次是负责处理订票的聚合根。我们看看一个车次包含了哪些信息？一个车次包括了：1）车次名称，如G71；2）座位数，实际座位数会分类型，比如商务座20个，一等座200个；二等座500个；我们这里为了简化问题，可以暂时忽略类型，我认为这个类型不影响核心的模型的设计决策。需要格外注意的是：这里的座位数不要理解为真实的物理座位数，很有可能比真实的座位数要少。因为我们不可能把一个车次的所有座位都在网上通过12306来出售，而是只出售一部分，具体出售多少，要由工作人员人工指定。 3）经过的站点信息（包括站点的ID、站点名称等），注意：车次还会记录这些站点之间的顺序关系；4）出发时间；看过GRASP九大模式中的信息专家模式的同学应该知道，将职责分配给拥有执行该职责所需信息的类。我们这个场景，车次具有一次出票的所有信息，所以我们应该把出票的职责交给车次。另外学过DDD的同学应该知道，聚合设计有一个原则，就是：聚合内强一致性，聚合之间最终一致性。经过上面的分析，我们知道要产生一张票，其实要影响很多和这个票对应的线段相交的其他票的可用数量。因为所有的站点信息都在车次聚合内部，所以车次聚合内部自然可以维护所有的原子区间，以及每个原子区间的可用票数（相当于是库存数）。当一个原子区间的可用票数为0的时候，意味着火车针对这个区间的票已经卖完了。所以，我们完全可以让车次这个聚合根来保证出票时对所有原子区间的可用票数的更新的强一致性。对于车次聚合根来说，这很简单，因为只是几次简单的内存操作而已，耗时可以忽略。一列火车假如有ABCD四个站点，那原子区间就是3个。对于G71，则是16个。怎么判断是否能出票基于上面的聚合设计，出票时扣减库存的逻辑是：根据订单信息，拿到出发地和目的地，然后获取这段区间里的所有的原子区间。然后尝试将每个原子区间的可用票数减1，如果所有的原子区间都够减，则购票成功；否则购票失败，提示用户该票已经卖完了。是不是很简单呢？知道了出票的逻辑，那退票的逻辑也就很简单了，就是把这个票的所有原子区间的可用票数加 1就OK了。如果我们从线段的厚度的角度去考虑，那出票时，每个原子区间的厚度就是+1，退票时就是减一。就是相反的操作，但本质是一样的。所以，通过这样的思路，我们将一次订票的处理控制在了一个聚合根里，用聚合根内的强一致性的特性保证了订票处理的强一致性，同时也保证了性能，免去了并发冲突的可能性。传统电商那种把票单做类似商品的核心聚合根的设计，我当时第一眼看到就觉得不妥。因为这违背了DDD强调的强一致性应该由聚合根来保证、聚合根之间的最终一致性通过Saga来保证的原则。还有一个很重要的概念我想说一下我的看法，就是座位和区间的关系。因为有些朋友和我讲，考虑座位号的问题，虽然都能减1，座位号也必须是同一个。我觉得座位是全局共享的，和区段无关（也许我的理解完全有误，请大家指正）。座位是一个物理概念，一个用户成功购买了一张票后，座位就会少一个，一张票唯一对应一个座位，但是一个座位有可能会对应多张票；而区间是一个逻辑上的概念，区间的作用有两个：1）表示票的出发地和目的地；2）记录票的可用数额。如果区间能连通（即该区间内的每个原子区间的可用数额都大于0），则表示允许拥有一个座位。所以，我觉得座位和票（区间）是两个维度的概念。如何为票分配座位我觉得车次聚合根内部应该维护所有该车次已经售出的票，已经出售的票的的本质是区间和座位的对应关系。系统处理订票时，用户提交过来的是一段区间。所以，系统应该做两个事情：先根据区间去判断是否有可用的座位；如果有可用座位，则再通过算法去选择一个可用的座位；当得到一个可用座位后，就可以生成一张票了，然后保存这个票到车次聚合根内部即可。下面举个例子：假设现在的情况是座位有3个，站点有4个座位：1,2,3站点：abcd票的卖法1：票1：ab,1票2：bc,2票3：cd,3票4：ac,3票5：bd,1这种选座位的方式应该比较高效，因为总是优先从座位池里去拿座位，只有在万不得已的时候才会去回收可重复利用的票。上面的4，5两个票，就是考虑回收利用的结果。票的卖法2：票1：ab,1票2：bc,1票3：cd,1票4：ac,2票5：bd,3这种选座位的方式应该相对低效，因为总是优先会去扫描是否有可回收的座位，而扫描相对直接从座位池里去拿票总是成本相对要高的。上面的2，3两个票，就是考虑回收利用的结果。但是，优先从座位池里拿票的算法有缺陷，就是会出现虽然第一步判断认为有可用的座位，但是这个座位可能不是全程都是同一个座位。举例：假设现在的情况是座位有3个，站点有4个座位：1,2,3站点：abcd票的卖法3：票1：ab,1票2：bc,2票3：cd,3现在如果有人要买ad的票，那可用的座位有2，或者3。但是无论是2还是3，都要这个乘客中途换车位。比如卖给他座位2，那他ab是坐的座位2，但是bc的时候要坐座位1的。否则拿票2的那个人上车时，发现座位2已经有人了。而通过优先回收利用的算法，是没这个问题的。所以，从上面的分析我们也知道选座位的算法该怎么写了，就是采用优先回收利用座位的算法。我认为不管我们这里怎么设计算法，都不影响大局，因为这一切都只发生在车次聚合根内部，这就是预先设计好聚合根，明确出票职责在哪个对象上的好处。模型分析总结我认为票不是核心聚合根，票只是一次出票的结果，一个凭证而已。12306真正的核心聚合根应该是车次，车次具有出票的职责，一次出票具体做的事情有：判断是否可出票；选择可用的座位；更新一次出票时所有原子区间的可用票数，用于判断下次是否能出票；维护所有已售出的票，用于为选择可用座位提供依据；通过这样的模型设计，我们可以确保一次出票处理只会在一个车次聚合根内进行。这样的好处是：不需要依赖数据库事务就能实现数据修改的强一致性，因为所有修改只在一个聚合根内发生；在保证数据强一致性的同时还能提供很高的并发处理能力，具体设计见下面的架构设计；架构设计（非本文重点，没兴趣的朋友可以略过）我觉得12306这样的业务场景，非常适合使用CQRS架构；因为首先它是一个查多写少、但是写的业务逻辑非常复杂的系统。所以，非常适合做架构层面的读写分离，即采用CQRS架构。而且应该使用数据存储也分离的CQRS。这样CQ两端才可以完全不需要顾及对方的问题，各自优化自己的问题即可。我们可以在C端使用DDD领域模型的思路，用良好设计的领域模型实现复杂的业务规则和业务逻辑。而Q端则使用分布式缓存方案，实现可伸缩的查询能力。订票的实现思路同时借助像ENode这样的框架，我们可以实现in-memory + Event Sourcing的架构。Event Sourcing技术，可以让领域模型的所有状态修改的持久化统一起来，本来要用ORM的方式保存聚合根最新状态的，现在只需要简单的通用的方式保存一个事件即可（一次订票只涉及一个车次聚合根的修改，修改只产生一个事件，只需要持久化一个事件（一个JSON串）即可，保证了高性能，无须依赖事务，而且通过ENode可以解决并发问题）。我们只要保存了聚合根每次变化的事件（事件的结构怎么设计，本文不做多的介绍了，大家可以思考下），就相当于保存了聚合根的最新状态。而正是由于Event Sourcing技术的引入，让我们的模型可以一直存活在内存中，即可以使用in-memory技术。不要小看in-memory技术，in- memory技术在某些方面对提高命令的处理性能非常有帮助。比如就以我们车次聚合根处理出票的逻辑，假设某个车次有大量的命令发送到分布式消息队列，然后有一台机器订阅了这个队列的消息，然后这台机器处理这个车次的订票命令时，由于这个车次聚合根一直在内存，所以就省去了每次要去数据库取出聚合根的步骤，相当于少了一次数据库IO。这样的好处是，因为一个车次能够真正出售的票是有限的，因为座位就那么几个，比如就1000个座位，估计一般正常情况也就出个2000个左右的票吧（具体能出多少张票要取决于区间的相交程度，上面分析过）。也就是说，这个聚合根只会产生2000个事件，也就是说只会有 2000个订票命令的处理是会产生事件，并持久化事件；而其余的大量命令，因为车次在内存计算后发现没有余票了，就不会做任何修改，也不会产生领域事件，这样就可以直接处理下一个订票命令了。这样就可以大大提高处理订票命令的性能。另外一个问题我觉得还需要提一下，因为用户订票成功后，还需要付款。但用户有可能不去付款或者没有在规定的时间内完成付款。那这种情况下，系统会自动释放该用户之前订购的票。所以基于这样的需求，我们在业务上需要支持业务级别的2pc。即先预扣库存，也就是先占住这张票一定时间（比如15分钟），然后付款成功后再真实给你这张票，系统做真正的库存修改。通过这样的预扣处理，可以保证不会出现超卖的情况。这个思路其实和传统电商比如淘宝这样的系统类似，我就不多展开了，我之前写的Conference案例也是这样的思路，大家有兴趣的可以去看一下我之前录制的视频。查询余票的实现思路我觉得余票的查询的实现相对简单。虽然对于12306来说，查询的请求占了80%，提交订单的请求只占20%。但查询由于对数据没有修改，所以我们完全可以使用分布式缓存来实现。我们只需要精心设计好缓存的key即可；缓存key的多少要看成本，如果所有可能的查询都设计对应的key，那时间复杂度为1，查询性能自然高；但代价也大，因为key多了。如果想key少一点，那查询的复杂度自然要上去一点。所以缓存设计无非就是空间换时间的思路。然后，缓存的更新无非就是：自动失效、定时更新、主动通知3种。通过CQRS架构，由于CQ两端是事件驱动的，当C端有任何状态变化，都会产生对应的事件去通知 Q端，所以我们几乎可以做到Q端的准实时更新。同时由于CQ两端的完全解耦，Q端我们可以设计多种存储，如数据库和缓存（Redis等）；数据库用于线下维护关系型数据，缓存用户实时查询。数据库和缓存的更新速度相互不受影响，因为是并行的。对同一个事件，可以10台机器负责更新缓存，100台机器负责更新数据库。即便数据库的更新很慢，也不会影响缓存的更新进度。这就是CQRS架构的好处，CQ的架构完全不同，且我们随时可以重建一种新的Q端存储。不知道大家体会到了没有？关于缓存key的设计，我觉得主要从查询余票时传递的信息来考虑。12306的关键查询是：出发地、目的地、出发日期三个信息。我觉得有两种key 的设计思路：1）直接设计了该查询条件的key，然后快速拿到车次信息，直接返回；这种方式就是要求我们系统已经枚举了所有车次的所有可能出现的票（区间）的缓存key，相信你一定知道这样的key是非常多的。2）不是枚举所有区间，而是把每个车次的每个原子区间（相邻的两个站点所连成的直线）的可用票数作为key。这样，key就非常少了，因为车次假如有10000个，然后每个车次平均15个区间，那也就15W个key而已。当我们要查询时，只需要把用户输入的出发地和目的地之间的所有原子区间的可用票数都查出来，然后比较出最小可用票数的那个原子区间。则这个原子区间的可用票数就是用户输入的区间的可用票数了。当然，到这里我提到考虑出发日期。我认为出发日期是用来决定具体是哪个车次聚合根的。同一个车次，不同的日期，对应的聚合根实例是不同的，即便是同一天，也可能有多个车次聚合根，因为有些车次一天有几班的，比如上午9点发车的一班，下午3点发车的一般。所以，我们也只要把日期也作为缓存key 的一部分即可。

文章TAG：中班数学数学题连线中班数学题连线