n******1
发帖数: 3756 | 1 我真没想到还在争12306这个话题，其中一个核心是关于transaction
由于自己的一些经验，我很容易理解好虫的方案，当然可能也是四平八稳，也没什么惊
喜。另外一些人的方案是跳出框架的约束，重新思考问题的本质，将商业逻辑抽象。我
没有能力判断两者的可行和好坏。
我自己也一直没法真正理解transaction这个问题，我尝试去读《Java Transaction
Design Strategies》这本书，但是说实在，我看不懂这本书，虽然很多人说这本书已
经是最好，最容易理解。
似乎从一开始我们接受了关系型数据库天生的解决方案，生来就有外键，需要关联，需
要transaction，没有我们就不知道该怎么办。很多时候我们想优化，都说因为这个那
个约束，最后说是瓶颈，没法解决。我们经常被DBA这样忽悠。
关系型数据库出现的时候，很多人可能都没出生，有时候我们也不知道为什么今天发展
到这个情况
最近我接触了MongoDB，相信现在很多人都接触过了，它就是把传统RDBMS传统一套抛弃
，重新获得解放，在一些情况下非常好用。它目前已经不支持document（类似table）
之间的transaction，意思就是如果你想更新一个表，同时又想更新第二个表的时候，
你不能将两个操作作为All or nothing进行处理。
如果你需要，就只能自己去实现。
它这里解释了怎么用transaction最经典的例子来做解释，只是由A账户转账100到B账户
，怎么实现这个需求。
这里很详细实现了用一个额外的document(table)去记录怎么two phase commit，怎么
rollback
http://docs.mongodb.org/manual/tutorial/perform-two-phase-commi
可以看出来已经很复杂 |
z****e
发帖数: 54598 | 2 少来
mongodb是nosql里面最像db的一个
可以说就是因为很多人离不开db
所以才选择了mongo
否则谁用？
我就不用，我要db的时候用postgresql
不需要的时候用cassandra |
z****e
发帖数: 54598 | 3 transaction因为太耗性能
而且无法scale out，所以才被提起
而要scale out自然会有所牺牲
这个牺牲往往就是数据的精度
当你的业务不涉及钱的时候
比如搜索引擎，这个精度是不可能绝对精准的
无所谓，但是一旦你的业务涉及金钱交易
那你往往不敢牺牲精度
因为一旦涉及金钱，错一点都要搞你半死
谁愿意让自己的钱少掉那么一点呢？
所以google卖个平板，并发才几十万还是几百万，就挂了 |
d*******r
发帖数: 3299 | 4 我倒是觉得lz很多理解得比较本质到点. Mongo 有时像传统 db，只是伪装，是无间道
而已.
我还是以前的观点，巨讨厌 SQL, RDBMS，从N年前本科学这玩意儿，就觉得用着憋屈，
就是一残疾.
一年一度的 12306 春晚帖又要开始了，哈哈 |
z****e
发帖数: 54598 | 5 mongo除了不支持transaction，其他就是一个db
根本说不上是一个nosql，跟db的共同点远多余跟其他nosql的共同点
cassandra什么才是对persistence的颠覆
【在 d*******r 的大作中提到】
: 我倒是觉得lz很多理解得比较本质到点. Mongo 有时像传统 db，只是伪装，是无间道
: 而已.
: 我还是以前的观点，巨讨厌 SQL, RDBMS，从N年前本科学这玩意儿，就觉得用着憋屈，
: 就是一残疾.
: 一年一度的 12306 春晚帖又要开始了，哈哈
|
z****e
发帖数: 54598 | 6 太多人思考问题时候脱离现实
一个最简单的思考
铁道部有没有现有的db？
当然有嘛
那怎么对付现有的db？
全部丢掉不用？
你是领导，你敢这么做？
你就忽悠吧 |
n******1
发帖数: 3756 | 7 好吧，我们可以开始讨论一下什么是DB
【在 z****e 的大作中提到】
: mongo除了不支持transaction，其他就是一个db
: 根本说不上是一个nosql，跟db的共同点远多余跟其他nosql的共同点
: cassandra什么才是对persistence的颠覆
|
d*******r
发帖数: 3299 | 8 哈哈，我也是被老赵的定义绕晕乎了
所以我提DB的时候，说的是 “传统DB”, 暗指 SQL, RDBMS 那一套东西
【在 n******1 的大作中提到】
: 好吧，我们可以开始讨论一下什么是DB
|
n******1
发帖数: 3756 | 9 来，你说说雅虎敢不敢抛弃它现在该死的门户，当某一天清晨起来，有人打开雅虎，然
后惊呼：妈呀，变天了，这还是雅虎吗
【在 z****e 的大作中提到】
: 太多人思考问题时候脱离现实
: 一个最简单的思考
: 铁道部有没有现有的db？
: 当然有嘛
: 那怎么对付现有的db？
: 全部丢掉不用？
: 你是领导，你敢这么做？
: 你就忽悠吧
|
z****e
发帖数: 54598 | 10 那这个文章大了
顺便，two phase commit是一种有缺陷的解决方案
并不能真正替代transaction
一般工作中还是尽量避免使用
因为网络本身并不稳定，第二次commit是有可能fail的
然后如何防止第二次commit挂掉，又有各种设计
这就是分布式算法一天到晚思考的问题
这些问题很棘手，所以一般工作中采用的方式是绕开
而不是迎头而上，否则你的麻烦可不小
常见的绕开就是分库，不要急着做成分布式
尤其是量比较小的时候，如果量大了的话，花点钱请点人
问问他们怎么做，如果你是接盘的，看看前人怎么做
前人做的work的话，就继续那么做
如果不work，那你接盘时候要小心点了，给自己留条退路未必是坏事
这个讨论短时间内不会有结果
【在 n******1 的大作中提到】
: 好吧，我们可以开始讨论一下什么是DB
|
|
|
z****e
发帖数: 54598 | 11 雅虎的文章错一点没啥大问题
但是涉及到金钱的东西
你错一分钱，可能都会加班一个晚上
你要是没有这个概念的话
先找份工作做做，不要想当然
【在 n******1 的大作中提到】
: 来，你说说雅虎敢不敢抛弃它现在该死的门户，当某一天清晨起来，有人打开雅虎，然
: 后惊呼：妈呀，变天了，这还是雅虎吗
|
n******1
发帖数: 3756 | 12 有点我真是很佩服你，就是你打字很快！
这是我在买买提见过打字最快的
【在 z****e 的大作中提到】
: 那这个文章大了
: 顺便，two phase commit是一种有缺陷的解决方案
: 并不能真正替代transaction
: 一般工作中还是尽量避免使用
: 因为网络本身并不稳定，第二次commit是有可能fail的
: 然后如何防止第二次commit挂掉，又有各种设计
: 这就是分布式算法一天到晚思考的问题
: 这些问题很棘手，所以一般工作中采用的方式是绕开
: 而不是迎头而上，否则你的麻烦可不小
: 常见的绕开就是分库，不要急着做成分布式
|
z****e
发帖数: 54598 | 13 对键盘的熟悉多少页反映出你编码的这个历史
【在 n******1 的大作中提到】
: 有点我真是很佩服你，就是你打字很快！
: 这是我在买买提见过打字最快的
|
n******1
发帖数: 3756 | 14 我是一个蹩脚的程序员，半路出家，复制粘贴起步
雅虎好像也搞些女郎，想粘点黄边，也没出色
【在 z****e 的大作中提到】
: 雅虎的文章错一点没啥大问题
: 但是涉及到金钱的东西
: 你错一分钱，可能都会加班一个晚上
: 你要是没有这个概念的话
: 先找份工作做做，不要想当然
|
n******1
发帖数: 3756 | 15 我还没承认你就是看出来了，这反映了两个问题，1，你打字很快，2 你打字确实很快
【在 z****e 的大作中提到】
: 对键盘的熟悉多少页反映出你编码的这个历史
|
z****e
发帖数: 54598 | 16 说得牛头不对马嘴的
精度说的是你把100写成99，就会有人闹事，比如告你老板这种
但是一般web网页，你说亚洲杯决赛刚刚澳大利亚2-0胜了韩国
都不会有人吃饱了去告你老板，你看招聘就很清楚了
一旦涉及财务组，对于db的要求就拉高了，要求懂oracle这些
但是如果不涉及财务，db要求就不是那么高，dba也不是都吃干饭的
人家也有点看家的本领
【在 n******1 的大作中提到】
: 我是一个蹩脚的程序员，半路出家，复制粘贴起步
: 雅虎好像也搞些女郎，想粘点黄边，也没出色
|
g*****g
发帖数: 34805 | 17 我给的不是什么传统方案，上来就是 异步Cassandra收单，云端动态Scale. 后者12306
已经在做了，但是前者才是解决问题的关键。
至于后端，一天出几百万张票，我知道大机器Oracle都能做到1万以上，他们用内存数
据库也不过做到3万，不是本质的区别。
【在 n******1 的大作中提到】
: 我真没想到还在争12306这个话题，其中一个核心是关于transaction
: 由于自己的一些经验，我很容易理解好虫的方案，当然可能也是四平八稳，也没什么惊
: 喜。另外一些人的方案是跳出框架的约束，重新思考问题的本质，将商业逻辑抽象。我
: 没有能力判断两者的可行和好坏。
: 我自己也一直没法真正理解transaction这个问题，我尝试去读《Java Transaction
: Design Strategies》这本书，但是说实在，我看不懂这本书，虽然很多人说这本书已
: 经是最好，最容易理解。
: 似乎从一开始我们接受了关系型数据库天生的解决方案，生来就有外键，需要关联，需
: 要transaction，没有我们就不知道该怎么办。很多时候我们想优化，都说因为这个那
: 个约束，最后说是瓶颈，没法解决。我们经常被DBA这样忽悠。
|
n******1
发帖数: 3756 | 18 我觉得键盘只是一个因素，如果用telnet终端会快一点，用网页又要点解又要提交，导
致效率无法提高。有时候我们不知道瓶颈在哪里，当然如果大家都用网页，你确实很快
【在 z****e 的大作中提到】
: 说得牛头不对马嘴的
: 精度说的是你把100写成99，就会有人闹事，比如告你老板这种
: 但是一般web网页，你说亚洲杯决赛刚刚澳大利亚2-0胜了韩国
: 都不会有人吃饱了去告你老板，你看招聘就很清楚了
: 一旦涉及财务组，对于db的要求就拉高了，要求懂oracle这些
: 但是如果不涉及财务，db要求就不是那么高，dba也不是都吃干饭的
: 人家也有点看家的本领
|
z****e
发帖数: 54598 | 19 现在其实就是异步＋cloud
订票和出票是两套系统在做
出票时候要自己去取票
订票时候mark一下就结束了
12306
【在 g*****g 的大作中提到】
: 我给的不是什么传统方案，上来就是 异步Cassandra收单，云端动态Scale. 后者12306
: 已经在做了，但是前者才是解决问题的关键。
: 至于后端，一天出几百万张票，我知道大机器Oracle都能做到1万以上，他们用内存数
: 据库也不过做到3万，不是本质的区别。
|
z****e
发帖数: 54598 | 20 好吧，你赢了，你的确很无聊，我不该回这贴
【在 n******1 的大作中提到】
: 我觉得键盘只是一个因素，如果用telnet终端会快一点，用网页又要点解又要提交，导
: 致效率无法提高。有时候我们不知道瓶颈在哪里，当然如果大家都用网页，你确实很快
|
|
|
n******1
发帖数: 3756 | 21 我也不理解什么是异步，为什么用异步，怎么用异步
有reference可以看吗？
【在 z****e 的大作中提到】
: 现在其实就是异步＋cloud
: 订票和出票是两套系统在做
: 出票时候要自己去取票
: 订票时候mark一下就结束了
:
: 12306
|
n******1
发帖数: 3756 | 22 我正在算是异步处理你的回复吗？
【在 z****e 的大作中提到】
: 好吧，你赢了，你的确很无聊，我不该回这贴
|
T*****9
发帖数: 2484 | 23 request都应该做成async的，但是在db应该满足transaction
同时可以看看类似于 Twitter的snow flake，出票的时候不同的机器可以负责一个自己
的range
【在 z****e 的大作中提到】
: 现在其实就是异步＋cloud
: 订票和出票是两套系统在做
: 出票时候要自己去取票
: 订票时候mark一下就结束了
:
: 12306
|
n******1
发帖数: 3756 | 24 重新思考原来我们认为理所当然的东西，是有必要的，是这样吗？
【在 T*****9 的大作中提到】
: request都应该做成async的，但是在db应该满足transaction
: 同时可以看看类似于 Twitter的snow flake，出票的时候不同的机器可以负责一个自己
: 的range
|
z****e
发帖数: 54598 | 25 legacy code
db本身就是一个非常大的legacy system
要改起来需要时间
现在绝大多数db操作都不是异步的
要改成异步的
目前做得比较靠谱的就是rxjava-jdbc
这个做出来之后，应该大多数db访问都会变成异步的
所以rxjava出来之后进一步打击了mongodb
本来mongodb被spark什么折磨得就很够呛了
twitter怎么做还是老话，twitter不涉及money
发错一个twit不会有太大问题，不值得参考
看看电商还比较靠谱点，至少应该看看twitter的财务组是怎么做的
【在 T*****9 的大作中提到】
: request都应该做成async的，但是在db应该满足transaction
: 同时可以看看类似于 Twitter的snow flake，出票的时候不同的机器可以负责一个自己
: 的range
|
