T********i
发帖数: 2416 | 1 关键就是fail以前的最后一个transaction总是不确定的。不论你采用什么机制，ack,
ack of ack, ack of ack of ack。。。
这是一个很简单的逻辑问题。单机都存在这个问题。这还是在不追求性能的条件的理论
最优解。多机partitioning只不过放大了这个问题。
如果追求性能，允许异步通信，那么单机不确定的数量会大于1。
刚看了jepsen，zookeeper也会出现fail以后elect多个master的问题。
因此，简化版本，两台单机client/server transaction。也必须两边记录journal log
。fail以后要有个两边对账的机制，才能保证100的consistency。
事实上，我没看到有这么做的。 |
l*********s
发帖数: 5409 | |
T********i
发帖数: 2416 | |
D*******a
发帖数: 3688 | 4 in distributed system you never know whether the recipient node is dead, or
just working very slowly.
in BBS you never know whether people are not interested, or are just writing
long posts
:D
【在 T********i 的大作中提到】
: 稍微提一点深刻的问题，就没人讨论了。
|
T********i
发帖数: 2416 | 5 我当年一串单机串联的设计，迄今也没人明白。呵呵。
or
writing
【在 D*******a 的大作中提到】
: in distributed system you never know whether the recipient node is dead, or
: just working very slowly.
: in BBS you never know whether people are not interested, or are just writing
: long posts
: :D
|
t**r
发帖数: 3428 | |
f*******t
发帖数: 7549 | |
T********i
发帖数: 2416 | 8 这些都差得远着呢。细节，细节决定一切。
【在 f*******t 的大作中提到】
: HBase强consistency靠的就是对帐
|
s*****r
发帖数: 43070 | |
w**z
发帖数: 8232 | 10 cap, 只能选两个， 大多数NoSQL 就牺牲c 了。你那单机牺牲的是哪个来保证c 的？
log
【在 T********i 的大作中提到】
: 关键就是fail以前的最后一个transaction总是不确定的。不论你采用什么机制，ack,
: ack of ack, ack of ack of ack。。。
: 这是一个很简单的逻辑问题。单机都存在这个问题。这还是在不追求性能的条件的理论
: 最优解。多机partitioning只不过放大了这个问题。
: 如果追求性能，允许异步通信，那么单机不确定的数量会大于1。
: 刚看了jepsen，zookeeper也会出现fail以后elect多个master的问题。
: 因此，简化版本，两台单机client/server transaction。也必须两边记录journal log
: 。fail以后要有个两边对账的机制，才能保证100的consistency。
: 事实上，我没看到有这么做的。
|
|
|
w***g
发帖数: 5958 | 11 我觉得你说的这个超过ACID的范畴了。
一个transaction玩了，client说commit，server成功执行，并且执行确认操作(ack)，
到此位置是consistency和durability的界限。如果因为什么原因client没有收到这个
ack，transaction也算是成功了。不然如你所说，ack of ack ...起来没完没了了，
就变成黑暗森林了。ack丢失的情况下要保证系统成功运行，得有强壮的业务逻辑才行。
log
【在 T********i 的大作中提到】
: 关键就是fail以前的最后一个transaction总是不确定的。不论你采用什么机制，ack,
: ack of ack, ack of ack of ack。。。
: 这是一个很简单的逻辑问题。单机都存在这个问题。这还是在不追求性能的条件的理论
: 最优解。多机partitioning只不过放大了这个问题。
: 如果追求性能，允许异步通信，那么单机不确定的数量会大于1。
: 刚看了jepsen，zookeeper也会出现fail以后elect多个master的问题。
: 因此，简化版本，两台单机client/server transaction。也必须两边记录journal log
: 。fail以后要有个两边对账的机制，才能保证100的consistency。
: 事实上，我没看到有这么做的。
|
T********i
发帖数: 2416 | 12 单机可能做到的只有C了。
一串单机的话，你说呢？
其实A纯粹是扯鸡巴蛋的事情。啥叫A？TCP丢包再传一个是不是就不A了？TCP断开重连
接是不是就不A了？server死掉fail over是不是就不A了？延迟多少算不A？1us？1ms？
1分钟？一小时？一天？
这个版上所有人的问题是，严格意义上讲，没有人做到了CP。 |
T********i
发帖数: 2416 | 13 所以说没有业务逻辑，不管你咋做数据库，你什么都保证不了。
你指望这些吃屎的能做好业务逻辑？
事实上，不管他们用啥，一旦任何一台机器当机，多少会丢一点。现实很骨感。快糙猛
的那些，丢掉两位数百分比都可以直接忽略。金钱相关的，一般都是手工对账的。
能稍微提高一点对账自动化的，现在还没人想呢。
我刚刚说了，其实A也是扯鸡巴蛋的事情，这个问题是伪问题，根本不存在。
行。
【在 w***g 的大作中提到】
: 我觉得你说的这个超过ACID的范畴了。
: 一个transaction玩了，client说commit，server成功执行，并且执行确认操作(ack)，
: 到此位置是consistency和durability的界限。如果因为什么原因client没有收到这个
: ack，transaction也算是成功了。不然如你所说，ack of ack ...起来没完没了了，
: 就变成黑暗森林了。ack丢失的情况下要保证系统成功运行，得有强壮的业务逻辑才行。
:
: log
|
k****i
发帖数: 101 | 14 Just my 2 cents below,
nodeX<--link-->nodeY
master-master-replicas
T(timeout)
a client request to update X:
X(T)---(1)SYN------>Y
X(T)<--(2)SYN+ACK---Y(T)
X------(3)ACK------>Y(T)
Inconsistency can occur on 3rd handshake. X need re-sync to Y thus meantime
return unavailable status to client requests, implicating A being dropped
for sake of CP.
【在 T********i 的大作中提到】
: 单机可能做到的只有C了。
: 一串单机的话，你说呢？
: 其实A纯粹是扯鸡巴蛋的事情。啥叫A？TCP丢包再传一个是不是就不A了？TCP断开重连
: 接是不是就不A了？server死掉fail over是不是就不A了？延迟多少算不A？1us？1ms？
: 1分钟？一小时？一天？
: 这个版上所有人的问题是，严格意义上讲，没有人做到了CP。
|
w**z
发帖数: 8232 | 15 A 的意思是任意一个节点down 了，整个cluster 还工作。如果是master slave, 就很
难support a， mongo 就是个例子。
【在 T********i 的大作中提到】
: 单机可能做到的只有C了。
: 一串单机的话，你说呢？
: 其实A纯粹是扯鸡巴蛋的事情。啥叫A？TCP丢包再传一个是不是就不A了？TCP断开重连
: 接是不是就不A了？server死掉fail over是不是就不A了？延迟多少算不A？1us？1ms？
: 1分钟？一小时？一天？
: 这个版上所有人的问题是，严格意义上讲，没有人做到了CP。
|
w**z
发帖数: 8232 | 16 你可以挑战 CAP theorem 了。
【在 T********i 的大作中提到】
: 所以说没有业务逻辑，不管你咋做数据库，你什么都保证不了。
: 你指望这些吃屎的能做好业务逻辑？
: 事实上，不管他们用啥，一旦任何一台机器当机，多少会丢一点。现实很骨感。快糙猛
: 的那些，丢掉两位数百分比都可以直接忽略。金钱相关的，一般都是手工对账的。
: 能稍微提高一点对账自动化的，现在还没人想呢。
: 我刚刚说了，其实A也是扯鸡巴蛋的事情，这个问题是伪问题，根本不存在。
:
: 行。
|
T********i
发帖数: 2416 | 17 你根本就不及格。回家多读几年书。别老上来扯淡。
你看看对A的定义。有谁敢说A就是这么定义的？就算是扯淡也不能这么个扯法。
【在 w**z 的大作中提到】
: A 的意思是任意一个节点down 了，整个cluster 还工作。如果是master slave, 就很
: 难support a， mongo 就是个例子。
|
w**z
发帖数: 8232 | 18 你还是比较适合做单机，worry about tcp 丢包啥的。看来你完全没有做过
distributed system。还单机串联。
【在 T********i 的大作中提到】
: 你根本就不及格。回家多读几年书。别老上来扯淡。
: 你看看对A的定义。有谁敢说A就是这么定义的？就算是扯淡也不能这么个扯法。
|
B********e
发帖数: 1062 | 19 自恋的都不知道去哪儿
好像就你在金融业工作一样，还手工对账？！烂人烂系统烂公司，还活在千禧年。
还单线程单机系统？！你说说看你知道的系统throughput多少？！
傻逼鸟事不懂，以为单个下单快就叫高频了。
【在 T********i 的大作中提到】
: 所以说没有业务逻辑，不管你咋做数据库，你什么都保证不了。
: 你指望这些吃屎的能做好业务逻辑？
: 事实上，不管他们用啥，一旦任何一台机器当机，多少会丢一点。现实很骨感。快糙猛
: 的那些，丢掉两位数百分比都可以直接忽略。金钱相关的，一般都是手工对账的。
: 能稍微提高一点对账自动化的，现在还没人想呢。
: 我刚刚说了，其实A也是扯鸡巴蛋的事情，这个问题是伪问题，根本不存在。
:
: 行。
|
g*****g
发帖数: 34805 | 20 他就写过点 client端程序，连 transaction都没整明白呢，谈分布式就是搞笑的。
【在 w**z 的大作中提到】
: 你还是比较适合做单机，worry about tcp 丢包啥的。看来你完全没有做过
: distributed system。还单机串联。
|
|
|
T********i
发帖数: 2416 | 21 看看，上来就是一帮谩骂的。上面wwzz和BonnieBrae帖子除了谩骂有一点技术含量没有？
wwzz, 你再说说availability的定义先？BonnieBrae你碰到过核心SQL数据库当机么？
很显然，单机系统你们都研究不明白。和wdong比起来差远了。 |
T********i
发帖数: 2416 | 22 goodbug又读不懂我的帖子开始抓狂了。蠢货们都喜欢聚堆在一起。 |
g*****g
发帖数: 34805 | 23 CAP里 A 只是说数据能读出来，不是 high availability的意思，否则 RDBMS 就不是
CA系统。当然在 分布式系统里基本是等价的。
【在 w**z 的大作中提到】
: A 的意思是任意一个节点down 了，整个cluster 还工作。如果是master slave, 就很
: 难support a， mongo 就是个例子。
|
g*****g
发帖数: 34805 | 24 读不懂太监的逻辑很正常。你这傻逼单机秒了 nasdaq整个 cluster的存档还有，吹牛
逼谁不会，关键别下面没有了。
【在 T********i 的大作中提到】
: goodbug又读不懂我的帖子开始抓狂了。蠢货们都喜欢聚堆在一起。
|
T********i
发帖数: 2416 | 25 让你们牵一下狗找出A的定义困难么？你这个说法也是不及格的。
随随便便就可以扯淡。也是醉了。
是
【在 g*****g 的大作中提到】
: CAP里 A 只是说数据能读出来，不是 high availability的意思，否则 RDBMS 就不是
: CA系统。当然在 分布式系统里基本是等价的。
|
B********e
发帖数: 1062 | 26 我靠，要是核心数据库当了，你们cto没有被解雇？
你们公司数据少到还用sql数据库存核心数据？
有？
【在 T********i 的大作中提到】
: 看看，上来就是一帮谩骂的。上面wwzz和BonnieBrae帖子除了谩骂有一点技术含量没有？
: wwzz, 你再说说availability的定义先？BonnieBrae你碰到过核心SQL数据库当机么？
: 很显然，单机系统你们都研究不明白。和wdong比起来差远了。
|
T********i
发帖数: 2416 | 27 把存档找出来。无耻的人将来全家都会遭报应的。呵呵。
【在 g*****g 的大作中提到】
: 读不懂太监的逻辑很正常。你这傻逼单机秒了 nasdaq整个 cluster的存档还有，吹牛
: 逼谁不会，关键别下面没有了。
|
g*****g
发帖数: 34805 | 28 我记不及格就不关你屁事了，你根本都没入门，没资格跟我谈这个。
【在 T********i 的大作中提到】
: 让你们牵一下狗找出A的定义困难么？你这个说法也是不及格的。
: 随随便便就可以扯淡。也是醉了。
:
: 是
|
T********i
发帖数: 2416 | 29 你连A的定义都说不对，怎么入的门？
【在 g*****g 的大作中提到】
: 我记不及格就不关你屁事了，你根本都没入门，没资格跟我谈这个。
|
T********i
发帖数: 2416 | 30 这个得Mark。了不起。合着已经能够掌握在全世界彻底淘汰SQL数据库的技术了。
【在 B********e 的大作中提到】
: 我靠，要是核心数据库当了，你们cto没有被解雇？
: 你们公司数据少到还用sql数据库存核心数据？
:
: 有？
|
|
|
B********e
发帖数: 1062 | 31 mark 吧， 老古董.
手工对账交易系统，牛逼。
【在 T********i 的大作中提到】
: 这个得Mark。了不起。合着已经能够掌握在全世界彻底淘汰SQL数据库的技术了。
|
g*****g
发帖数: 34805 | 32 我老不用像你临时Google，我说的即使不是他正式定义的，也是等价的。像你这样的外
行只会比单词。
【在 T********i 的大作中提到】
: 你连A的定义都说不对，怎么入的门？
|
T********i
发帖数: 2416 | 33 你的原话：
CAP里 A 只是说数据能读出来，不是 high availability的意思，否则 RDBMS 就不是
CA系统。当然在 分布式系统里基本是等价的。
问题，读数据返回说数据读不出来，让你过一秒钟后重试。还是不是A？
你给我证明个等价看看。
【在 g*****g 的大作中提到】
: 我老不用像你临时Google，我说的即使不是他正式定义的，也是等价的。像你这样的外
: 行只会比单词。
|
g*****g
发帖数: 34805 | 34 数据存在就能读出来，不存在就读不出来。你丫想套我是没用的。
是
【在 T********i 的大作中提到】
: 你的原话：
: CAP里 A 只是说数据能读出来，不是 high availability的意思，否则 RDBMS 就不是
: CA系统。当然在 分布式系统里基本是等价的。
: 问题，读数据返回说数据读不出来，让你过一秒钟后重试。还是不是A？
: 你给我证明个等价看看。
|
T********i
发帖数: 2416 | 35 数据刚刚写进去，还没来及发ACK。有人一锤子把机器砸稀巴烂。硬盘还好。
你说数据是存在呢？还是不存在？
【在 g*****g 的大作中提到】
: 数据存在就能读出来，不存在就读不出来。你丫想套我是没用的。
:
: 是
|
N*****m
发帖数: 42603 | 36 按有的观点，现实世界P是永远存在的，最多只能满足CP或者AP，不存在CA系统
所以RDBMS确实不是A，只有C
是
【在 T********i 的大作中提到】
: 你的原话：
: CAP里 A 只是说数据能读出来，不是 high availability的意思，否则 RDBMS 就不是
: CA系统。当然在 分布式系统里基本是等价的。
: 问题，读数据返回说数据读不出来，让你过一秒钟后重试。还是不是A？
: 你给我证明个等价看看。
|
w**z
发帖数: 8232 | 37 我哪里谩骂了？找出证据了，别以为谁都和你一样low。
有？
【在 T********i 的大作中提到】
: 看看，上来就是一帮谩骂的。上面wwzz和BonnieBrae帖子除了谩骂有一点技术含量没有？
: wwzz, 你再说说availability的定义先？BonnieBrae你碰到过核心SQL数据库当机么？
: 很显然，单机系统你们都研究不明白。和wdong比起来差远了。
|
g*****g
发帖数: 34805 | 38 所以这就是 available, but not high available. SPOF.
【在 T********i 的大作中提到】
: 数据刚刚写进去，还没来及发ACK。有人一锤子把机器砸稀巴烂。硬盘还好。
: 你说数据是存在呢？还是不存在？
|
w**z
发帖数: 8232 | 39 你也只是牵狗的水平，我们都是天天在实战中打拼的。还说tcp 丢包，就不是A， 你搞
笑吧？
【在 T********i 的大作中提到】
: 让你们牵一下狗找出A的定义困难么？你这个说法也是不及格的。
: 随随便便就可以扯淡。也是醉了。
:
: 是
|
T********i
发帖数: 2416 | 40 其实除了P以外，其他都不存在。
我已经证明了。
【在 N*****m 的大作中提到】
: 按有的观点，现实世界P是永远存在的，最多只能满足CP或者AP，不存在CA系统
: 所以RDBMS确实不是A，只有C
:
: 是
|
|
|
w**z
发帖数: 8232 | 41 CAP 只是在分布式的系统里讨论才有意义，你的单机根本不在讨论范围内。
是
【在 T********i 的大作中提到】
: 你的原话：
: CAP里 A 只是说数据能读出来，不是 high availability的意思，否则 RDBMS 就不是
: CA系统。当然在 分布式系统里基本是等价的。
: 问题，读数据返回说数据读不出来，让你过一秒钟后重试。还是不是A？
: 你给我证明个等价看看。
|
T********i
发帖数: 2416 | 42 你别闹了。单机恰恰是CA系统。
只有一台以上才会顶多有P。剩下的啥都没有了。
【在 w**z 的大作中提到】
: CAP 只是在分布式的系统里讨论才有意义，你的单机根本不在讨论范围内。
:
: 是
|
N*****m
发帖数: 42603 | 43 paxos, raft还是可以保证的
ectd是老中写的，不知道上不上本版
log
【在 T********i 的大作中提到】
: 关键就是fail以前的最后一个transaction总是不确定的。不论你采用什么机制，ack,
: ack of ack, ack of ack of ack。。。
: 这是一个很简单的逻辑问题。单机都存在这个问题。这还是在不追求性能的条件的理论
: 最优解。多机partitioning只不过放大了这个问题。
: 如果追求性能，允许异步通信，那么单机不确定的数量会大于1。
: 刚看了jepsen，zookeeper也会出现fail以后elect多个master的问题。
: 因此，简化版本，两台单机client/server transaction。也必须两边记录journal log
: 。fail以后要有个两边对账的机制，才能保证100的consistency。
: 事实上，我没看到有这么做的。
|
T********i
发帖数: 2416 | 44 慢点来，其实还是能保证的。就是尤其是写性能难以保证罢了。
单机能CA，理论上没理由多机不能是不是？
问题是那些成天把CAP挂在嘴边的。最后就剩一个屁。然后一坨坨往上糊，就号称C或者
A了。
其实我那个一串单机，碰到问题再重新拓扑的架构也没啥不好。至少throughput比这两
个还好呢。呵呵。
【在 N*****m 的大作中提到】
: paxos, raft还是可以保证的
: ectd是老中写的，不知道上不上本版
:
: log
|
w**z
发帖数: 8232 | 45 昨天C＊ summit 几千人参加，原来都是去吃屎的。你咋不整个串联单机summit， 看看
多少人捧你的臭脚？
【在 T********i 的大作中提到】
: 慢点来，其实还是能保证的。就是尤其是写性能难以保证罢了。
: 单机能CA，理论上没理由多机不能是不是？
: 问题是那些成天把CAP挂在嘴边的。最后就剩一个屁。然后一坨坨往上糊，就号称C或者
: A了。
: 其实我那个一串单机，碰到问题再重新拓扑的架构也没啥不好。至少throughput比这两
: 个还好呢。呵呵。
|
T********i
发帖数: 2416 | 46 即使CA都不满足，也会有很多应用。C*是个啥东西，能干啥不能干啥，参加的知道的门
清的应该有的是。
搞不清楚的是你自己。别把别人扯进来。
【在 w**z 的大作中提到】
: 昨天C＊ summit 几千人参加，原来都是去吃屎的。你咋不整个串联单机summit， 看看
: 多少人捧你的臭脚？
|
w**z
发帖数: 8232 | 47 我日常工作一部分就是搞这个， 我如果不清楚， 就没几个人清楚了。你就牵狗，然后
来装逼，瞎喷。
【在 T********i 的大作中提到】
: 即使CA都不满足，也会有很多应用。C*是个啥东西，能干啥不能干啥，参加的知道的门
: 清的应该有的是。
: 搞不清楚的是你自己。别把别人扯进来。
|
T********i
发帖数: 2416 | 48 你说了这么多，除了反复强调你是搞
这个的。我不是搞这个的。还说过啥
有技术含量的？你的帖子都在。你自
己去找找看。
【在 w**z 的大作中提到】
: 我日常工作一部分就是搞这个， 我如果不清楚， 就没几个人清楚了。你就牵狗，然后
: 来装逼，瞎喷。
|
g*****g
发帖数: 34805 | 49 多机当然能CA，不就是一partition，整个系统就挂吗，那就是CA。不过只有脑残才这
么做分布式系统。
【在 T********i 的大作中提到】
: 慢点来，其实还是能保证的。就是尤其是写性能难以保证罢了。
: 单机能CA，理论上没理由多机不能是不是？
: 问题是那些成天把CAP挂在嘴边的。最后就剩一个屁。然后一坨坨往上糊，就号称C或者
: A了。
: 其实我那个一串单机，碰到问题再重新拓扑的架构也没啥不好。至少throughput比这两
: 个还好呢。呵呵。
|
g*****g
发帖数: 34805 | |
|
|
T********i
发帖数: 2416 | 51 你个蠢货。你刚刚说过了不是high availability也是A。等一万年出结果也是A是不是？
你做的那些玩意儿。就是一个P。和CA都不沾边。
【在 g*****g 的大作中提到】
: 多机当然能CA，不就是一partition，整个系统就挂吗，那就是CA。不过只有脑残才这
: 么做分布式系统。
|
T********i
发帖数: 2416 | 52 这种自说自话的帖子。你就别现眼了。
C*不是已经有人做出throughput高一个数量级的了吗？
什么单机beat nasdaq集群之类的。你把我原话找出来。造谣死全家的。
【在 g*****g 的大作中提到】
: 你丫就是三天不打脸忘了自己是太监。
: 傻逼单机beat nasdaq集群。
: http://www.mitbbs.com/article_t1/Programming/31287951_0_1.html
: 傻逼挑战CAP theorem.
: http://www.mitbbs.com/article_t1/Programming/31286965_31287013_
|
g*****g
发帖数: 34805 | 53 傻逼你懂中文吗？这跟我说的有矛盾吗？不是high availability 也是A没有错，所以
你设计个分布式系统，一partition就全挂，也叫CA。当然只有你这样的脑残才会这么
做系统。
是？
【在 T********i 的大作中提到】
: 你个蠢货。你刚刚说过了不是high availability也是A。等一万年出结果也是A是不是？
: 你做的那些玩意儿。就是一个P。和CA都不沾边。
|
g*****g
发帖数: 34805 | 54 你这傻逼单机每秒500万交易，轻松灭了nasdaq，数据在那里，还敢死撑？
【在 T********i 的大作中提到】
: 这种自说自话的帖子。你就别现眼了。
: C*不是已经有人做出throughput高一个数量级的了吗？
: 什么单机beat nasdaq集群之类的。你把我原话找出来。造谣死全家的。
|
T********i
发帖数: 2416 | 55 啥叫挂？拒绝服务一毫秒叫不叫挂？拒绝服务一分钟叫不叫挂？
你怎么证明我的架构一partition就挂？
【在 g*****g 的大作中提到】
: 傻逼你懂中文吗？这跟我说的有矛盾吗？不是high availability 也是A没有错，所以
: 你设计个分布式系统，一partition就全挂，也叫CA。当然只有你这样的脑残才会这么
: 做系统。
:
: 是？
|
T********i
发帖数: 2416 | 56 我还每秒5000万计数器呢。数据也在那里。
你给我找出来我号称单机500万交易的服务器的帖子来。
这种张嘴就造谣的，不知道爹妈咋生养的。
【在 g*****g 的大作中提到】
: 你这傻逼单机每秒500万交易，轻松灭了nasdaq，数据在那里，还敢死撑？
|
g*****g
发帖数: 34805 | 57 你丫要做的是 12306卖票，不是 transaction是啥？傻逼敢吹不敢认呀。你丫全家早他
妈死光了。
【在 T********i 的大作中提到】
: 我还每秒5000万计数器呢。数据也在那里。
: 你给我找出来我号称单机500万交易的服务器的帖子来。
: 这种张嘴就造谣的，不知道爹妈咋生养的。
|
w**z
发帖数: 8232 | 58 我已经说得很清楚了，只不过你没做过， 看不懂而已。
【在 T********i 的大作中提到】
: 你说了这么多，除了反复强调你是搞
: 这个的。我不是搞这个的。还说过啥
: 有技术含量的？你的帖子都在。你自
: 己去找找看。
|
T********i
发帖数: 2416 | 59 蠢货。计数器也是transaction。难道不是？transaction就都一样？
你数据库是体育老师教的？
人品如此下作。这绝对是爹妈生养的问题。
【在 g*****g 的大作中提到】
: 你丫要做的是 12306卖票，不是 transaction是啥？傻逼敢吹不敢认呀。你丫全家早他
: 妈死光了。
|
w**z
发帖数: 8232 | 60 古德吧有耐心，和你争，我没那么多时间和你吵，同样的话，来回说，没啥意思。你自
己慢慢玩吧。
【在 w**z 的大作中提到】
: 我已经说得很清楚了，只不过你没做过， 看不懂而已。
|
|
|
T********i
发帖数: 2416 | 61 古德吧连transaction都一样那种下三滥话都能说出来。
果然和你是一类人。呵呵。
【在 w**z 的大作中提到】
: 古德吧有耐心，和你争，我没那么多时间和你吵，同样的话，来回说，没啥意思。你自
: 己慢慢玩吧。
|
g*****g
发帖数: 34805 | 62 这我管不着，反正吹了做不出来都是太监。单机计数500万次不叫500万个交易，你至少得
有request/response吧。
【在 T********i 的大作中提到】
: 蠢货。计数器也是transaction。难道不是？transaction就都一样？
: 你数据库是体育老师教的？
: 人品如此下作。这绝对是爹妈生养的问题。
|
T********i
发帖数: 2416 | 63 你这么不要脸，被我抓住还能一笑而过。这个要不是从小耳濡目染，还真不太可能形成。
家教呀。家教。
【在 g*****g 的大作中提到】
: 这我管不着，反正吹了做不出来都是太监。单机计数500万次不叫500万个交易，你至少得
: 有request/response吧。
|
g*****g
发帖数: 34805 | 64 我当然能一笑而过，你这太监丢人躲了两年，哪次不是出来满血复活。
成。
【在 T********i 的大作中提到】
: 你这么不要脸，被我抓住还能一笑而过。这个要不是从小耳濡目染，还真不太可能形成。
: 家教呀。家教。
|
T********i
发帖数: 2416 | 65 你至贱无敌。我每次都甘拜下风。这个我承认。
【在 g*****g 的大作中提到】
: 我当然能一笑而过，你这太监丢人躲了两年，哪次不是出来满血复活。
:
: 成。
|
g*****g
发帖数: 34805 | 66 不吹牛逼就不会连鸡鸡都没有了。
【在 T********i 的大作中提到】
: 你至贱无敌。我每次都甘拜下风。这个我承认。
|
h**********c
发帖数: 4120 | 67 关于这个先要明确需求
需求是要求response time还是要求fault tolerance
我老很震惊的是目前市场对计算机这种机器基本性能的忽略，一个出色的机械工程师或
者结构工程师首先考虑的问题是机器不能干什么，然后才考虑机器可以干什么。
如果fault tolerance是优先需求，绝对不允许写失误。
那么应该参考raid的设计，采用n＞2个独立处理单元，计算同一笔业务，然后对结果进
行投票。
log
【在 T********i 的大作中提到】
: 关键就是fail以前的最后一个transaction总是不确定的。不论你采用什么机制，ack,
: ack of ack, ack of ack of ack。。。
: 这是一个很简单的逻辑问题。单机都存在这个问题。这还是在不追求性能的条件的理论
: 最优解。多机partitioning只不过放大了这个问题。
: 如果追求性能，允许异步通信，那么单机不确定的数量会大于1。
: 刚看了jepsen，zookeeper也会出现fail以后elect多个master的问题。
: 因此，简化版本，两台单机client/server transaction。也必须两边记录journal log
: 。fail以后要有个两边对账的机制，才能保证100的consistency。
: 事实上，我没看到有这么做的。
|
T********i
发帖数: 2416 | 68 其实wdong说到点子上了。没有强大的业务逻辑。数据库其实基本啥都保证不了。
现实应用本来出现错误基本都需要人来对账。不明白这个的，根本不配号称是搞技术的。
比如你在amazon买东西，下单后返回一个白屏。你说这单有没有成功？这就需要你自己
重新登录自己查你的下单记录。amazon会管你么？根本不会。
整个straight through processing一般参与的数据库也不止一个。业务逻辑做的不对,
如果缺乏这种对账机制，系统根本不可用。不管你用啥数据库，设计的时候一个ID
scheme设计不周全，你就是到时候对不了帐。到时候你说希望人家数据库vendor帮你保
证C，怎么可能？
persistent messaging system with incremental ID是根本。要想保证C，没有这个是
不可能的。
【在 h**********c 的大作中提到】
: 关于这个先要明确需求
: 需求是要求response time还是要求fault tolerance
: 我老很震惊的是目前市场对计算机这种机器基本性能的忽略，一个出色的机械工程师或
: 者结构工程师首先考虑的问题是机器不能干什么，然后才考虑机器可以干什么。
: 如果fault tolerance是优先需求，绝对不允许写失误。
: 那么应该参考raid的设计，采用n＞2个独立处理单元，计算同一笔业务，然后对结果进
: 行投票。
:
: log
|
h**********c
发帖数: 4120 | 69 说白还是建模能力，把复杂问题简化抽象，
我看那个大熟菊正是反向运做，本质是反智的反进步的。
的。
对,
【在 T********i 的大作中提到】
: 其实wdong说到点子上了。没有强大的业务逻辑。数据库其实基本啥都保证不了。
: 现实应用本来出现错误基本都需要人来对账。不明白这个的，根本不配号称是搞技术的。
: 比如你在amazon买东西，下单后返回一个白屏。你说这单有没有成功？这就需要你自己
: 重新登录自己查你的下单记录。amazon会管你么？根本不会。
: 整个straight through processing一般参与的数据库也不止一个。业务逻辑做的不对,
: 如果缺乏这种对账机制，系统根本不可用。不管你用啥数据库，设计的时候一个ID
: scheme设计不周全，你就是到时候对不了帐。到时候你说希望人家数据库vendor帮你保
: 证C，怎么可能？
: persistent messaging system with incremental ID是根本。要想保证C，没有这个是
: 不可能的。
|
h**********c
发帖数: 4120 | 70 是邪恶的，必须送交Inquisition and grill some of the astray souls
【在 h**********c 的大作中提到】
: 说白还是建模能力，把复杂问题简化抽象，
: 我看那个大熟菊正是反向运做，本质是反智的反进步的。
:
: 的。
: 对,
|
|
|
w***g
发帖数: 5958 | 71 人类科学发展到这一步，最大驱动力是求生存，第二大是求交配，
要我看第三大就是偷懒了。前两年两个热点，一个大数据，一个
deep learning，其本质都是要靠brutal force来取代人类的创造
力。从目前看来，不管其目的如何，客观上反而是极大地促进了
人类创造力的发挥。人类邪(xian)恶(jin)的社会机制保证了不管
技术多进步，大部分人都还是得做牛做马，真正能实现偷懒的永远
只是少数人。所以技术会一直进步。
【在 h**********c 的大作中提到】
: 说白还是建模能力，把复杂问题简化抽象，
: 我看那个大熟菊正是反向运做，本质是反智的反进步的。
:
: 的。
: 对,
|
T********i
发帖数: 2416 | 72 这个persistent messaging system with incremental ID是根本，
完全是我个人的总结。
有人说这不就是kafka么？其实我这人孤陋寡闻。kafka也是最近才听说。这个系统倒是
用了10来年了，都是自己写的。
要做成一个系统，知道需要啥，为啥需要，是最重要的。反正我喜欢做没人做过的东西。
【在 h**********c 的大作中提到】
: 说白还是建模能力，把复杂问题简化抽象，
: 我看那个大熟菊正是反向运做，本质是反智的反进步的。
:
: 的。
: 对,
|
h**********c
发帖数: 4120 | 73 人多的地方就有是非，要求同存异，向三个哥们学习
现在的程序员愿意堆码晒行数，工业化还是要打造高标准的零件，才能向更高层次抽象。
否则就是对人类最高端投资的亵渎。
很庆幸我们生活在一个丰收的时代，也许在历史书上，我们却是躺在面包上打滚的败类。
西。
【在 T********i 的大作中提到】
: 这个persistent messaging system with incremental ID是根本，
: 完全是我个人的总结。
: 有人说这不就是kafka么？其实我这人孤陋寡闻。kafka也是最近才听说。这个系统倒是
: 用了10来年了，都是自己写的。
: 要做成一个系统，知道需要啥，为啥需要，是最重要的。反正我喜欢做没人做过的东西。
|
T********i
发帖数: 2416 | 74 其实背着抱着一般沉。几百行就写出来的东西。真没必要搞那么复杂。都不够那个学习
成本，更不用说性能了。
其实细看都是一坨坨。我自己做的我也不满意。别人做的也是能挑出一堆毛病。至少自
己做的还能知道弱点在什么地方。
我最近做了一个系统。IDE和Source Control都是自己做的。我有一个Bare minimum的
设计观点。还没在别的地方看到过。
象。
类。
【在 h**********c 的大作中提到】
: 人多的地方就有是非，要求同存异，向三个哥们学习
: 现在的程序员愿意堆码晒行数，工业化还是要打造高标准的零件，才能向更高层次抽象。
: 否则就是对人类最高端投资的亵渎。
: 很庆幸我们生活在一个丰收的时代，也许在历史书上，我们却是躺在面包上打滚的败类。
:
: 西。
|
h**********c
发帖数: 4120 | 75 中国人对社会化的大生产的体会应该是最深刻，我老对于小作坊生产模式强烈质疑。不
过在北米显学道，不上github的确是不太entertain
【在 T********i 的大作中提到】
: 其实背着抱着一般沉。几百行就写出来的东西。真没必要搞那么复杂。都不够那个学习
: 成本，更不用说性能了。
: 其实细看都是一坨坨。我自己做的我也不满意。别人做的也是能挑出一堆毛病。至少自
: 己做的还能知道弱点在什么地方。
: 我最近做了一个系统。IDE和Source Control都是自己做的。我有一个Bare minimum的
: 设计观点。还没在别的地方看到过。
:
: 象。
: 类。
|
T********i
发帖数: 2416 | 76 其实都是取决于利益。上不上github取决于是否有利。
当然，最后都要给人用。谁的东西用的人多才是王道。我个人对大生产没啥看法。我只
知道萝卜快了不洗泥。对质量不要有不切实际的期望就好了。
【在 h**********c 的大作中提到】
: 中国人对社会化的大生产的体会应该是最深刻，我老对于小作坊生产模式强烈质疑。不
: 过在北米显学道，不上github的确是不太entertain
|
h****r
发帖数: 2056 | 77 raft就算了吧
【在 N*****m 的大作中提到】
: paxos, raft还是可以保证的
: ectd是老中写的，不知道上不上本版
:
: log
|
h**********c
发帖数: 4120 | 78 您老酒香不怕巷子深，须要很深的定力
现在的requirement都要求＂click one button", then lay back on the elysium
beach
【在 T********i 的大作中提到】
: 其实都是取决于利益。上不上github取决于是否有利。
: 当然，最后都要给人用。谁的东西用的人多才是王道。我个人对大生产没啥看法。我只
: 知道萝卜快了不洗泥。对质量不要有不切实际的期望就好了。
|
g*****g
发帖数: 34805 | 79 屁都不懂的就是吭哧做轮子，做半天跟开源的一比就是垃圾。
【在 h**********c 的大作中提到】
: 您老酒香不怕巷子深，须要很深的定力
: 现在的requirement都要求＂click one button", then lay back on the elysium
: beach
|
c*********e
发帖数: 16335 | 80 写开源代码的都是什么人？有人给他工资吗？
【在 g*****g 的大作中提到】
: 屁都不懂的就是吭哧做轮子，做半天跟开源的一比就是垃圾。
|
|
|
h**********c
发帖数: 4120 | 81 很多开源作者都是住老爹老妈地下室里，牺牲自己的happiness搞点东西出来，有那种
公司动不动来个＂we dont' support it anymore"
【在 c*********e 的大作中提到】
: 写开源代码的都是什么人？有人给他工资吗？
|
h**********c
发帖数: 4120 | 82 很多公司的项目就是一quitter
【在 h**********c 的大作中提到】
: 很多开源作者都是住老爹老妈地下室里，牺牲自己的happiness搞点东西出来，有那种
: 公司动不动来个＂we dont' support it anymore"
|
T********i
发帖数: 2416 | 83 很多开源软件做的不错。我用很多开源代码。
但是到我这里一行不改就能用的不多。很多都被我大改了。
Kafka那样的我还真用不着。第一我只需要考虑我的需求。没必要满足所有人都需求。
第二，我的latency和throughput要求比kafka的性能高一个数量级。怎么用？
【在 h**********c 的大作中提到】
: 很多公司的项目就是一quitter
|
h**********c
发帖数: 4120 | 84 你可以有kafa申请项目，钱到手了，＂I change my mind"
【在 T********i 的大作中提到】
: 很多开源软件做的不错。我用很多开源代码。
: 但是到我这里一行不改就能用的不多。很多都被我大改了。
: Kafka那样的我还真用不着。第一我只需要考虑我的需求。没必要满足所有人都需求。
: 第二，我的latency和throughput要求比kafka的性能高一个数量级。怎么用？
|
T********i
发帖数: 2416 | 85 Kafka我还真不懂。Scala一点都不会。
【在 h**********c 的大作中提到】
: 你可以有kafa申请项目，钱到手了，＂I change my mind"
|
h**********c
发帖数: 4120 | 86 你需要can do 的态度
【在 T********i 的大作中提到】
: Kafka我还真不懂。Scala一点都不会。
|
T********i
发帖数: 2416 | 87 呵呵。Can't do。真的用不着scala。
【在 h**********c 的大作中提到】
: 你需要can do 的态度
|
a******e
发帖数: 82 | 88 我去，还就看见一个脑袋清楚的人。
行。
【在 w***g 的大作中提到】
: 我觉得你说的这个超过ACID的范畴了。
: 一个transaction玩了，client说commit，server成功执行，并且执行确认操作(ack)，
: 到此位置是consistency和durability的界限。如果因为什么原因client没有收到这个
: ack，transaction也算是成功了。不然如你所说，ack of ack ...起来没完没了了，
: 就变成黑暗森林了。ack丢失的情况下要保证系统成功运行，得有强壮的业务逻辑才行。
:
: log
|
a******e
发帖数: 82 | 89 后面你说什么我没有看懂，但是第一个ack, ack of ack... 我在本科计算机网络第一
堂课老师举得第一个例子，就是这个，说的是任何protocol都有这个问题。但是，这个
和relational database的ACID是两码事，consistent只是server端的consistent。
log
【在 T********i 的大作中提到】
: 关键就是fail以前的最后一个transaction总是不确定的。不论你采用什么机制，ack,
: ack of ack, ack of ack of ack。。。
: 这是一个很简单的逻辑问题。单机都存在这个问题。这还是在不追求性能的条件的理论
: 最优解。多机partitioning只不过放大了这个问题。
: 如果追求性能，允许异步通信，那么单机不确定的数量会大于1。
: 刚看了jepsen，zookeeper也会出现fail以后elect多个master的问题。
: 因此，简化版本，两台单机client/server transaction。也必须两边记录journal log
: 。fail以后要有个两边对账的机制，才能保证100的consistency。
: 事实上，我没看到有这么做的。
|
h**********c
发帖数: 4120 | 90 no ack of ack, the client may send the transaction again.
【在 a******e 的大作中提到】
: 后面你说什么我没有看懂，但是第一个ack, ack of ack... 我在本科计算机网络第一
: 堂课老师举得第一个例子，就是这个，说的是任何protocol都有这个问题。但是，这个
: 和relational database的ACID是两码事，consistent只是server端的consistent。
:
: log
|
|
|
h**********c
发帖数: 4120 | 91 一般应该是ack of ack then end of dialog
【在 a******e 的大作中提到】
: 后面你说什么我没有看懂，但是第一个ack, ack of ack... 我在本科计算机网络第一
: 堂课老师举得第一个例子，就是这个，说的是任何protocol都有这个问题。但是，这个
: 和relational database的ACID是两码事，consistent只是server端的consistent。
:
: log
|
T********i
发帖数: 2416 | 92 赞一下你讨论问题的态度。
当然，一般人都应该知道server端收到commit。完成动作，返回一个成功
transaction就算成功了。它不管你有没有收到这个 。
但是别忘了。稍微大一点的系统，client不是直接access数据库server的。甚至一般都
要访问几个数据库。
客户在乎的不是你单个数据库是不是consisyent。是你整个系统是否consistent。不收
钱给你货你不会抱怨。收了你钱不发货你就不干了。
分布式数据库每台机器都是client/server。你又怎么保证consistent呢？
【在 a******e 的大作中提到】
: 后面你说什么我没有看懂，但是第一个ack, ack of ack... 我在本科计算机网络第一
: 堂课老师举得第一个例子，就是这个，说的是任何protocol都有这个问题。但是，这个
: 和relational database的ACID是两码事，consistent只是server端的consistent。
:
: log
|
a******e
发帖数: 82 | |
