Author Topic: 提高交易效率的方案  (Read 9777 times)

0 Members and 1 Guest are viewing this topic.

Offline cdryan

  • Sr. Member
  • ****
  • Posts: 357
    • View Profile
算法和方案可以优化, 但无法跨越硬件瓶颈,硬件,带宽和安全上,目前的代表pc都不足以支撑起金融交易的要求.
软件改善的同时,
以后应该设计一套方案, 竞争出更强大的代表.

Offline gyhy

  • Hero Member
  • *****
  • Posts: 852
    • View Profile

Offline urbanpauper

  • Full Member
  • ***
  • Posts: 112
    • View Profile
btsx: urbanpauper

Offline freedom

  • Sr. Member
  • ****
  • Posts: 303
    • View Profile
这方案好啊,另外还有那么多备用代表,处理还不够可以全都利用起来。 :) :)

应该反应给BM,早做打算

Offline zhao150

  • Hero Member
  • *****
  • Posts: 606
  • 老子早就不想当代表了
    • View Profile
我也说点什么吧!
不错,赚了钱 来捐款
老子早就不想当代表了

Offline cdryan

  • Sr. Member
  • ****
  • Posts: 357
    • View Profile
alt兄这种帖子一定要赞扬阿. +5% +5% +5% +5% +5% +5%
最近我也一直在思考这个问题.因为 BTX 面向的是金融交易.
这一问题必须有好的解决方案,DAC才能真正的走向应用级.
如果把这个问题真正的解决,BTS就真正的走向moon了.

Offline Yao

  • Hero Member
  • *****
  • Posts: 534
    • View Profile
  • BitShares: yao
  • GitHub: imYao
并行处理的确是个好的方向,但是由于网络的复杂性,一定要想出简单易行高效的方法。

成大事者,除了个人能力突出外,一定要获得上天的眷顾才能成功;欣慰的是,bm周边围绕了一群敬爱他的才华横溢的忠粉,这就是上天给予bm的眷顾。 :P
+5%
BM就是唐僧,alt是调皮捣蛋专打妖怪的大师兄,现在在3i开发团队的黑人鱼是沙师弟?八戒、白龙马赶紧跟上 :P

Offline Yao

  • Hero Member
  • *****
  • Posts: 534
    • View Profile
  • BitShares: yao
  • GitHub: imYao
并行处理应该是值得考虑的,等BM把眼前事处理完了我再去烦他  ;D


恩,先不要砸场
等先出了钱包再伺机做空  :-X :-X :-X

熊熊,做空的时候告诉我一声 :P
« Last Edit: July 02, 2014, 11:40:06 am by Yao »

Offline Yao

  • Hero Member
  • *****
  • Posts: 534
    • View Profile
  • BitShares: yao
  • GitHub: imYao
悟空(alt)已然成为 bitshares 开发的重要中国力量。
印证了沈波的话:bitshares,中国一起干!

Offline Musewhale

  • Hero Member
  • *****
  • Posts: 2881
  • 丑,实在是太丑了 !
    • View Profile
并行处理应该是值得考虑的,等BM把眼前事处理完了我再去烦他  ;D


恩,先不要砸场
等先出了钱包再伺机做空  :-X :-X :-X
MUSE witness:mygoodfriend     vote for me

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
并行处理应该是值得考虑的,等BM把眼前事处理完了我再去烦他  ;D

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
谢谢大家支持,等大家都发财了再打赏我吧  :D
很多想法我是想当然的还不成熟,仅为了抛砖引玉,大家别见笑就行

Offline dcchong

  • Sr. Member
  • ****
  • Posts: 203
    • View Profile
并行处理的确是个好的方向,但是由于网络的复杂性,一定要想出简单易行高效的方法。

成大事者,除了个人能力突出外,一定要获得上天的眷顾才能成功;欣慰的是,bm周边围绕了一群敬爱他的才华横溢的忠粉,这就是上天给予bm的眷顾。 :P
wallet_approve_delegate dc-delegate true
wallet_approve_delegate bitsharesx-delegate true

Offline nj-racoon

  • Full Member
  • ***
  • Posts: 85
    • View Profile

Offline ALAN---

  • Jr. Member
  • **
  • Posts: 21
  • btsx: bocai
    • View Profile
作为啥也不懂的小白,只能默默的给你们鼓掌,替你们加油打气,加油。。。。。

Offline ssjpts

  • Hero Member
  • *****
  • Posts: 538
    • View Profile
    • 中国BTC
  • BitShares: coolman
alt是大师兄呀,建议捐赠的BTS给予像alt这样有卓出贡献的人一定的奖励。
新浪微博:剑指未来BTS
BTC:1Bc7gRGotktBmnNFr3BUUM22HFXCCTyxor
BTSX ID:loves,集大众之爱,待到BTS 500刀,10%回退给捐赠者,10%用于运营,剩余80%用于爱心事业和BTS宣传推广。

Offline gyhy

  • Hero Member
  • *****
  • Posts: 852
    • View Profile
第1点应该可以实现
第2点,还待讨论。

Offline metalallen

  • Sr. Member
  • ****
  • Posts: 262
    • View Profile
浮壹白的微博:http://weibo.com/u/2279693077
BTSX Account:metalallen

Offline PTS中国

  • Sr. Member
  • ****
  • Posts: 416
    • View Profile
  • BitShares: ptschina
现在测试网络DRYRUN7的两个主要指标:15秒出块,交易频率限制为 2trx/s。
我认为BTS XT第一次发布如果有这样的性能已经很好了,应对半年内的应用应该是没问题的。

为了应对以后大规模的交易应用,以下是我认为可行的改进方案:
1. 每个代理出块数及频率都改为动态自适应的。
1.1 首先确定本轮101个代理工作顺序,每个代理分配1分钟的可支配时钟片。
1.2 这里引进一个定义: heartbeat 心跳数据。每个代理在开始工作时广播心跳开始信号,结束时广播心跳结束信号(包含本轮自己生产了多少个块)。所有代理的心跳数据建立了代理协同工作的同步机制。因为心跳数据包很小,估计能保证 3s 的延时。
1.3 当前代理接收到上一个代理的心跳结束信号后,先发送心跳开始信号,等待接收完所有数据块后就可生产区块。这里等待心跳结束信号或者等待区块数据包到达都有超时机制,可设为 15s。
1.4 当前代理生产区块的频率不固定,满50个交易,或者1分钟时间到了就可以产生区块。当交易量很大时,每1秒钟就生成一个区块都有可能。
1.5 在结束本轮工作时广播一个心跳结束信号。
1.6 如果一个交易都没有就不要生产区块了,直接发送心跳结束信号
1.7 下一个代理开始工作

这个方案是我认为比较高效的协同工作机制。其性能会受到网络带宽、CPU等限制。以带宽来算,假设是10M网络,可稳定传输100K/秒的数据,一个交易250个字节,大概的处理能力是 400trx/秒。确认时间为 1秒 ~ 1分钟。

2. 这个性能还不足以和VISA竞争,为此要引入并行生产的方式,在每一个时刻能有多个代理同时工作。为了不因此增加协同工作的复杂性,需要严格分区,明确每个代理负责的区域。
一个简单的规则,比如分为100个块,按交易的HASH值除以100的余数分区域。这样能并行出块。这样处理能力就到40000trx/秒了。 :D

以上是个人理解,不知道是否准确

BM取经的路上有兄相伴,真乃大业幸事,亦是众粉丝幸事。

有个想法,心跳方案应该是异步单线程的处理模式,如果网络异常稳固,采用全网同步并行模式,那处理能力就是质的飞跃了。这个时候可以不用心跳,每个受托人掐表准时开始工作....
--------

PTS中国

Offline helloworld

  • Full Member
  • ***
  • Posts: 108
    • View Profile
社区需要更多像alt这样的人。 +5%
BTS:bts-hero

Offline codinat

  • Full Member
  • ***
  • Posts: 176
    • View Profile

Offline Snail

  • Hero Member
  • *****
  • Posts: 750
    • View Profile
  • BitShares: snail

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
现在测试网络DRYRUN7的两个主要指标:15秒出块,交易频率限制为 2trx/s。
我认为BTS XT第一次发布如果有这样的性能已经很好了,应对半年内的应用应该是没问题的。

为了应对以后大规模的交易应用,以下是我认为可行的改进方案:
1. 每个代理出块数及频率都改为动态自适应的。
1.1 首先确定本轮101个代理工作顺序,每个代理分配1分钟的可支配时钟片。
1.2 这里引进一个定义: heartbeat 心跳数据。每个代理在开始工作时广播心跳开始信号,结束时广播心跳结束信号(包含本轮自己生产了多少个块)。所有代理的心跳数据建立了代理协同工作的同步机制。因为心跳数据包很小,估计能保证 3s 的延时。
1.3 当前代理接收到上一个代理的心跳结束信号后,先发送心跳开始信号,等待接收完所有数据块后就可生产区块。这里等待心跳结束信号或者等待区块数据包到达都有超时机制,可设为 15s。
1.4 当前代理生产区块的频率不固定,满50个交易,或者1分钟时间到了就可以产生区块。当交易量很大时,每1秒钟就生成一个区块都有可能。
1.5 在结束本轮工作时广播一个心跳结束信号。
1.6 如果一个交易都没有就不要生产区块了,直接发送心跳结束信号
1.7 下一个代理开始工作

这个方案是我认为比较高效的协同工作机制。其性能会受到网络带宽、CPU等限制。以带宽来算,假设是10M网络,可稳定传输100K/秒的数据,一个交易250个字节,大概的处理能力是 400trx/秒。确认时间为 1秒 ~ 1分钟。

2. 这个性能还不足以和VISA竞争,为此要引入并行生产的方式,在每一个时刻能有多个代理同时工作。为了不因此增加协同工作的复杂性,需要严格分区,明确每个代理负责的区域。
一个简单的规则,比如分为100个块,按交易的HASH值除以100的余数分区域。这样能并行出块。这样处理能力就到40000trx/秒了。 :D

以上是个人理解,不知道是否准确