T********i
发帖数: 2416 | 1 一旦网络出现中断。不论是暂时还是永久性的。上游要进行一套route discovery
process。其实底层的TCP会试图寻找新的route或者重连接。
现在说说我的高层系统方案。
我说过了，上下游是单机绝对串行。什么叫串行不解释了。
一旦网络断开。上游机可以永远假设是永久性断开，着火或者核爆无所谓。这时他试图
连接下游的下游的那台机器。这个是在网络层的，router来处理就好了。
现在有两种情况：
1。下游的下游也连不上。这已经超出了你的只有一台DC fail的假定。大规模坏死谁也
没有更好的办法。当然了。我的方案还可以试着连下游的下游的下游。能连上照样无缝
failover。嘉定我们肯花钱多搞一台备份机的话。
2. 下游的下游能连上。这时候两种可能：
A. 下游的下游发现不对，怎么两台上游连我了？会拒绝。让你重复recovery过程。
其实两台机器都能连下游的下游说明是有route的。属于非永久性断开。这时再重连接
就好了。
B。下游确实死掉了。连接下游的下游。开始短暂的sync过程。
这个串行机制是本系统内的。一切都将在可控之内。唯一的外部因素是用户browser的
连接和网银的连接。网银连接设置这种单帐号双连接检测很容易。我不认为是问题。
客户browser更不是问题了。recovery过程fail所有的session就好了。你online
shopping，click payment button。网页一片白没响应了。很常见。到底买到没买到？
只能过一会儿再查查。 |
P********l
发帖数: 452 | 2 请教，你假定DC之间用的公网，不是专线？
DC之间的拓扑结构是一串，是吧？ 这样DC-DC-DC-DC。这个有什么好处呢？
你的高性能web server听起来有点玄。上次你讲道是在一个open source的软件基础上
改进的。能不能介绍一下，发个连接之类的。
【在 T********i 的大作中提到】
: 一旦网络出现中断。不论是暂时还是永久性的。上游要进行一套route discovery
: process。其实底层的TCP会试图寻找新的route或者重连接。
: 现在说说我的高层系统方案。
: 我说过了，上下游是单机绝对串行。什么叫串行不解释了。
: 一旦网络断开。上游机可以永远假设是永久性断开，着火或者核爆无所谓。这时他试图
: 连接下游的下游的那台机器。这个是在网络层的，router来处理就好了。
: 现在有两种情况：
: 1。下游的下游也连不上。这已经超出了你的只有一台DC fail的假定。大规模坏死谁也
: 没有更好的办法。当然了。我的方案还可以试着连下游的下游的下游。能连上照样无缝
: failover。嘉定我们肯花钱多搞一台备份机的话。
|
T********i
发帖数: 2416 | 3
当然是专线。
有人不服气，非要做跨DC的failover。要求一个DC被核爆老百姓还能上网买火车票。
多花点钱每个DC放一台。注意就放一台！让他们闭嘴。
mongoose。以前是BSD的。现在改成GPL V2了。但是我仍然可以用老的BSD代码hoho。
【在 P********l 的大作中提到】
: 请教，你假定DC之间用的公网，不是专线？
: DC之间的拓扑结构是一串，是吧？ 这样DC-DC-DC-DC。这个有什么好处呢？
: 你的高性能web server听起来有点玄。上次你讲道是在一个open source的软件基础上
: 改进的。能不能介绍一下，发个连接之类的。
|
P********l
发帖数: 452 | 4
goodbug的意思还是单独一个DC没有足够的throughput保存，要依靠DC之间备份．你好
像也认可．对吧？（帖子太多，我没跟全．抱歉）
除了一台单机，DC里还有什么其他配置吗？fzz可能对这个也感兴趣．
你说的是单机．一台单机，对吧？
多谢．
另外，如果不麻烦，能不能大概整个过程简单描述一下．就是你所说的打酱油的机器．
比如从用户角度，静态的文件从哪里去取？ 你的web server怎么做？订单查询的过程
（谁问谁要什么）？ checkout过程能简单划分一下就更好了．
多谢．
【在 T********i 的大作中提到】
:
: 当然是专线。
: 有人不服气，非要做跨DC的failover。要求一个DC被核爆老百姓还能上网买火车票。
: 多花点钱每个DC放一台。注意就放一台！让他们闭嘴。
: mongoose。以前是BSD的。现在改成GPL V2了。但是我仍然可以用老的BSD代码hoho。
|
T********i
发帖数: 2416 | 5 不好意思先简答一下。
web server其实就是两种操作。
1。接受用户输入。始发终点时间
2。从cache server看有没有票。
3。如果有，让用户输入划钱信息。
4。帮用户抢票。从主核心server抢。
【在 P********l 的大作中提到】
:
: goodbug的意思还是单独一个DC没有足够的throughput保存，要依靠DC之间备份．你好
: 像也认可．对吧？（帖子太多，我没跟全．抱歉）
: 除了一台单机，DC里还有什么其他配置吗？fzz可能对这个也感兴趣．
: 你说的是单机．一台单机，对吧？
: 多谢．
: 另外，如果不麻烦，能不能大概整个过程简单描述一下．就是你所说的打酱油的机器．
: 比如从用户角度，静态的文件从哪里去取？ 你的web server怎么做？订单查询的过程
: （谁问谁要什么）？ checkout过程能简单划分一下就更好了．
: 多谢．
|
f****4
发帖数: 1359 | 6 恩，我是感兴趣的 ^_^
这块东西，我没办法和goodbug摆摆：我不管你什么技术，号称能做到怎么样。没有资
源让我验证的情况下我只能忽略，不然我没办法往后面推了。
我和goodbug不一样的地方是，他那里只要缺什么，随口就来个方案，这个方案肯定是
解决了这个问题。但是把这个方案放到整个设计里面会带来怎么样的影响，他是压根不
考虑的。。。
就现在这么粗的一个设计，压根还没开始做详细设计的情况下。你动一次设计，我就的
重推一次——我做到现在，最变态的客户也没到这样的地步啊 -_-
老实说，有点脑力不够用了。。。
【在 P********l 的大作中提到】
:
: goodbug的意思还是单独一个DC没有足够的throughput保存，要依靠DC之间备份．你好
: 像也认可．对吧？（帖子太多，我没跟全．抱歉）
: 除了一台单机，DC里还有什么其他配置吗？fzz可能对这个也感兴趣．
: 你说的是单机．一台单机，对吧？
: 多谢．
: 另外，如果不麻烦，能不能大概整个过程简单描述一下．就是你所说的打酱油的机器．
: 比如从用户角度，静态的文件从哪里去取？ 你的web server怎么做？订单查询的过程
: （谁问谁要什么）？ checkout过程能简单划分一下就更好了．
: 多谢．
|
m*******l
发帖数: 12782 | 7 某些人就是知道堆砌名词而已
【在 f****4 的大作中提到】
: 恩，我是感兴趣的 ^_^
: 这块东西，我没办法和goodbug摆摆：我不管你什么技术，号称能做到怎么样。没有资
: 源让我验证的情况下我只能忽略，不然我没办法往后面推了。
: 我和goodbug不一样的地方是，他那里只要缺什么，随口就来个方案，这个方案肯定是
: 解决了这个问题。但是把这个方案放到整个设计里面会带来怎么样的影响，他是压根不
: 考虑的。。。
: 就现在这么粗的一个设计，压根还没开始做详细设计的情况下。你动一次设计，我就的
: 重推一次——我做到现在，最变态的客户也没到这样的地步啊 -_-
: 老实说，有点脑力不够用了。。。
|
g*****g
发帖数: 34805 | 8 常识太缺乏了魏老师，我就问主力 DC某个时间跟其他 dc 连不上了，怎么办？是继续
处理还是不处理？
连不上是可能是间歇性的，也可能是永久的，你发生的时候没法知道。
怎么样，你主力到底继续处理还是不处理？不处理的话是从什么时间开始不处理的？ |
T********i
发帖数: 2416 | 9 我的回答很清楚了。楼上那么多人都看懂了。
你看不懂是基本功的问题。
【在 g*****g 的大作中提到】
: 常识太缺乏了魏老师，我就问主力 DC某个时间跟其他 dc 连不上了，怎么办？是继续
: 处理还是不处理？
: 连不上是可能是间歇性的，也可能是永久的，你发生的时候没法知道。
: 怎么样，你主力到底继续处理还是不处理？不处理的话是从什么时间开始不处理的？
|
T********i
发帖数: 2416 | 10 老实说我也有失误。那个hot standby其实就是败笔。没有仔细思考的产物。
过后想想还是我现在用的方案靠谱。
主力机一串，串行。跨DC。
主力机里面只有一个是干活的。干活的管仲裁抢票叫队长。必然是这一串里面第一台。
第一台的消息给第二台发出去，第二胎给第三台等等。发消息异步。TCP只管写。ACK可
以是异步的。
二三四台也就管管
1. 传递上下游的消息。
2. 根据消息事实更新状态。
这一串主力机跨DC，任何一台死掉，就绕过他。sync一下可能丢失的状态。然后正常工
作。
其他的，每个主力机，不管是不是队长。可以在本地DC内brocast一些状态cache机。共
状态查询用。这样scalability无限扩展。每台状态cache可以多服务500万每秒。
【在 f****4 的大作中提到】
: 恩，我是感兴趣的 ^_^
: 这块东西，我没办法和goodbug摆摆：我不管你什么技术，号称能做到怎么样。没有资
: 源让我验证的情况下我只能忽略，不然我没办法往后面推了。
: 我和goodbug不一样的地方是，他那里只要缺什么，随口就来个方案，这个方案肯定是
: 解决了这个问题。但是把这个方案放到整个设计里面会带来怎么样的影响，他是压根不
: 考虑的。。。
: 就现在这么粗的一个设计，压根还没开始做详细设计的情况下。你动一次设计，我就的
: 重推一次——我做到现在，最变态的客户也没到这样的地步啊 -_-
: 老实说，有点脑力不够用了。。。
|
|
|
T********i
发帖数: 2416 | 11 要做到跨DC failover。DC带宽必须足够。状态都出不去，死掉就丢了。
其实那每天顶多上千万张的车票，需要多少带宽？
关键是我的系统响应和容量跟上去了。
【在 P********l 的大作中提到】
:
: goodbug的意思还是单独一个DC没有足够的throughput保存，要依靠DC之间备份．你好
: 像也认可．对吧？（帖子太多，我没跟全．抱歉）
: 除了一台单机，DC里还有什么其他配置吗？fzz可能对这个也感兴趣．
: 你说的是单机．一台单机，对吧？
: 多谢．
: 另外，如果不麻烦，能不能大概整个过程简单描述一下．就是你所说的打酱油的机器．
: 比如从用户角度，静态的文件从哪里去取？ 你的web server怎么做？订单查询的过程
: （谁问谁要什么）？ checkout过程能简单划分一下就更好了．
: 多谢．
|
h*****a
发帖数: 1718 | 12 这是不是和master-slave比较接近？还是就是一样？
【在 T********i 的大作中提到】
: 老实说我也有失误。那个hot standby其实就是败笔。没有仔细思考的产物。
: 过后想想还是我现在用的方案靠谱。
: 主力机一串，串行。跨DC。
: 主力机里面只有一个是干活的。干活的管仲裁抢票叫队长。必然是这一串里面第一台。
: 第一台的消息给第二台发出去，第二胎给第三台等等。发消息异步。TCP只管写。ACK可
: 以是异步的。
: 二三四台也就管管
: 1. 传递上下游的消息。
: 2. 根据消息事实更新状态。
: 这一串主力机跨DC，任何一台死掉，就绕过他。sync一下可能丢失的状态。然后正常工
|
T********i
发帖数: 2416 | 13 基本一样。
【在 h*****a 的大作中提到】
: 这是不是和master-slave比较接近？还是就是一样？
|
h*****a
发帖数: 1718 | 14 那就有个leader election的问题。你是把节点（DC）排好序了是吧？
其实确实很多现成的open source解决方案，比如zookeeper，考虑的很周全而且在现
中被不断检验。
【在 T********i 的大作中提到】
: 基本一样。
|
T********i
发帖数: 2416 | 15 对，排好序了。
zookeeper没用过。谢信息。
【在 h*****a 的大作中提到】
: 那就有个leader election的问题。你是把节点（DC）排好序了是吧？
: 其实确实很多现成的open source解决方案，比如zookeeper，考虑的很周全而且在现
: 中被不断检验。
|
T********i
发帖数: 2416 | 16 赞一下你这个leader election。
你一语中的。goodbug已经纠结一天了。
【在 h*****a 的大作中提到】
: 那就有个leader election的问题。你是把节点（DC）排好序了是吧？
: 其实确实很多现成的open source解决方案，比如zookeeper，考虑的很周全而且在现
: 中被不断检验。
|
g*****g
发帖数: 34805 | 17 原来你连leader election都不懂，还有脸谈failover?
你的问题是内存数据库，是内存数据库就有网络断加断电的风险，你再绕也是绕不出去
的。
【在 T********i 的大作中提到】
: 赞一下你这个leader election。
: 你一语中的。goodbug已经纠结一天了。
|
T********i
发帖数: 2416 | |
S*A
发帖数: 7142 | 19 大家不要急，我是想学习一下。
这个内存数据部分我也没有看懂，想请教一下魏老师。
关键是你 ACK 的时候，这个订单数据有没有确认写到 不是内存的（硬盘，SSD是快点
的硬盘）
的东西里面？ 通过网络让其他机器把这个数据写到硬盘里也
可以。但是同样要等写盘的延时。可以看成网络只不过是把硬盘延伸，
多个并发的硬盘。
如果数据还在内存没有到硬盘的话，那大家一起断电就会有订单丢失了。
这个比网站不能用还可怕，我定了票，系统告诉我定到了，结果没定上。
还没有完全理解你的方案是如何处理这个，前面可能有细节没看到。
再讲讲？ |
T********i
发帖数: 2416 | 20 上了十大推荐了。
看来除了goodbug其他大多数人都明白了。
世界观崩溃了会不会死，当年对法轮功信徒大家也有这个疑问？醒悟了会怎样？ |
|
|
z****e
发帖数: 54598 | 21 我的文章上十大推荐还有首页是常事
包括针对你的两篇，钻风直接给推荐上首页
看来其他绝大多数人比你更早明白
【在 T********i 的大作中提到】
: 上了十大推荐了。
: 看来除了goodbug其他大多数人都明白了。
: 世界观崩溃了会不会死，当年对法轮功信徒大家也有这个疑问？醒悟了会怎样？
|
z****e
发帖数: 54598 | 22 pipeline只是big data paradigm中的一种
还有master-workers
divide－conquer
single program-multiple data
speculation
这四种paradigm
请问你是如何address其他四种paradigm的？
我老板跟我说的
你这种水平要来见我老板
很是堪忧啊
【在 T********i 的大作中提到】
: 一旦网络出现中断。不论是暂时还是永久性的。上游要进行一套route discovery
: process。其实底层的TCP会试图寻找新的route或者重连接。
: 现在说说我的高层系统方案。
: 我说过了，上下游是单机绝对串行。什么叫串行不解释了。
: 一旦网络断开。上游机可以永远假设是永久性断开，着火或者核爆无所谓。这时他试图
: 连接下游的下游的那台机器。这个是在网络层的，router来处理就好了。
: 现在有两种情况：
: 1。下游的下游也连不上。这已经超出了你的只有一台DC fail的假定。大规模坏死谁也
: 没有更好的办法。当然了。我的方案还可以试着连下游的下游的下游。能连上照样无缝
: failover。嘉定我们肯花钱多搞一台备份机的话。
|
z****e
发帖数: 54598 | 23 pipeline处理方式恰好是各个paradigm里面最不愿意被使用的一种
一般如果不是大规模科学计算，依赖性比较强的处理
都不会这么搞，哪怕是event-driven这种很明显的pipeline
也是多个并发一起上，一般只有不得不pipeline时候，才会pipeline |
z****e
发帖数: 54598 | 24 古德霸其他人说的master-workers的方式恰好是分布式最常见的paradigm
谁没用过呀，老魏的思想太陈旧了
要不老魏你说一个学术会议吧，我过去看看你的发言
我们这块至少在icws上是常客，欢迎你来呀
那样就可以当面交流了，bbs上废话多没意思啊 |
z****e
发帖数: 54598 | 25 上次接待的acm大牛对chaos monkey推崇有加呀
老魏你这个让chaos monkey进去砸一顿你看如何？
呵呵 |
c***n
发帖数: 809 | 26 上游机器连接下游的下游? 这已经开始破环系统的模块化了。 那天下游机决定换个
存储下游，你还要通知所有上游？这种设计思路最终大不了， 同时没法维护。
【在 T********i 的大作中提到】
: 一旦网络出现中断。不论是暂时还是永久性的。上游要进行一套route discovery
: process。其实底层的TCP会试图寻找新的route或者重连接。
: 现在说说我的高层系统方案。
: 我说过了，上下游是单机绝对串行。什么叫串行不解释了。
: 一旦网络断开。上游机可以永远假设是永久性断开，着火或者核爆无所谓。这时他试图
: 连接下游的下游的那台机器。这个是在网络层的，router来处理就好了。
: 现在有两种情况：
: 1。下游的下游也连不上。这已经超出了你的只有一台DC fail的假定。大规模坏死谁也
: 没有更好的办法。当然了。我的方案还可以试着连下游的下游的下游。能连上照样无缝
: failover。嘉定我们肯花钱多搞一台备份机的话。
|
z****e
发帖数: 54598 | 27 如果是master-workers
压根不需要串行
老魏又开始声东击西了
总是嘴巴上说一个东西
然后慢慢就演变成另外一个东西
就跟当初web server -> app server
单机->分布式的演变一样
【在 h*****a 的大作中提到】
: 这是不是和master-slave比较接近？还是就是一样？
|
z****e
发帖数: 54598 | 28 一针见血
【在 c***n 的大作中提到】
: 上游机器连接下游的下游? 这已经开始破环系统的模块化了。 那天下游机决定换个
: 存储下游，你还要通知所有上游？这种设计思路最终大不了， 同时没法维护。
|
