Differences between revisions 4 and 5
⇤ ← Revision 4 as of 2006-01-05 08:10:55 →
Size: 4708
Editor: ZoomQuiet
Comment:
← Revision 5 as of 2006-01-05 08:11:41 → ⇥
Size: 4716
Editor: ZoomQuiet
Comment:
Deletions are marked like this. Additions are marked like this.
Line 54: Line 54:
 1. "k68所有的内容都利用KT存放在大家的电脑上" -- 不可能,用户体验也太差  1. '''k68所有的内容都利用KT存放在大家的电脑上''' -- 不可能,用户体验也太差
Line 56: Line 56:
 1. "“链式反应”...然后向周围的10个KT用户自动传送" -- 应该优先向任务发起人提交  1. '''“链式反应”...然后向周围的10个KT用户自动传送''' -- 应该优先向任务发起人提交

KT本质

嗬嗬,快速和阿康交流,确认了KT 的开发目标和技术难点,记要,以组织大家学习,参与

K68本质

江湖任务悬赏榜

  • K68的任务流程如下:

    提交任务
    ->审核
        ->交款K68保存
            ->悬赏公布->甄选成果->满意->付款结束
                        |               ^
                        |<----------+   |
                        |           |   |
                        +不满意->延期,加钱 |
                            |           |
                            + 强制选定---|

  • K68关注的任务:一周内,10小时内可以完成的任务

  • K68关注的人群:16--14有一定技术和大把空闲时间的学生

  • K68的目标:100万注册用户,每用户平均每年悬赏4项任务,每日10000新增任务

KT目标

一个P2P格局的任务交易平台

  • 已知统计信息:

    1. 平均每任务最终尺寸:10Mb

    2. 每日最少KT在线数量:7%

    3. 上传下载总平均速度:50kb

  • 设计指标:

    1. 每用户最大分享空间:1Gb

    2. 每新递交任务扩散到所有人可知时限:2小时

    3. 任务查询极限情况下遍历所有种子时限:3分钟

      • 即,含有所需信息的机器离查询机最远情况
    4. 没有中央服务器,所有信息冗余分布式存储在所有机器中

我的理解

KT想成为特立独行的任务发布系统

  • 本质上是一种专用邮件列表

    1. 所有任务,所有人都可以看到
    2. 所有任务的所有成果所有人都可以看到
    3. 所有历史任务的所有信息都可以查询到
  • 特别的是:
    1. 没有中央服务器,任务靠自动扩散来完成通知
    2. 所有文件,分布式存储在所有机器中
  • 我的设计思路:
    1. KT只完成一种,没有中央服务版本的
      • KT_mother 仅仅是代号,表示一种运行方式,是最早运行的一个KT,对所有任务"感兴趣"
      • KT_sister 也是代号,表示所有其它KT运行机,只要保证7*24的运行,其实也成为了KT_mother
    2. 任务信息分两部分(效仿 newsgroup):
      • 任务描述作为摘要(邮件主题对待),自动同步到所有KT空间
      • 任务的成果等等(邮件正文,附件),KT空间中只保存用户订阅/参与/查询过的,并有清除的权力
      • 任务的成果,从所有KT实例网络整体中,存在至少一个完整复制
        • 可以想象为一个由KT组成的互联网,每个KT是个网路,所有KT的内容加起来可以组成完整内容的多个复本
    3. 任务成果的搜索从本地DB中进行
      • 本地DB中的信息,允许24小时的慢同步时间差
      • 任务成果的下载,采用Bt的方式进行

KT需要的调整

  1. k68所有的内容都利用KT存放在大家的电脑上 -- 不可能,用户体验也太差

    • KT应该积极为用户考虑,保存所有必要的信息,灵活的帮助用户进行任务的管理

  2. “链式反应”...然后向周围的10个KT用户自动传送 -- 应该优先向任务发起人提交

KT需要设计的数学模型

  1. 搜索路径模型

    设: N* 为KT Seed节点,N0 为KT_mother,Nc 为当前节点
p 为每个KT处理请求平均时间,t 为每1Mb 通过KT节点的平均时间
则:
    180(秒)= 2*(t*10+p*2*(n-1))
    n 为从任意节点,扩散搜索到KT_mother节点要经过的节点数
    需要引入其它什么元素来令以上工程合理?

  2. 冗余存储模型

    设: C 为KT网络整体数据单位 ,N 为KT所有节点数量
Nmin为最小在线KT节点数,Nmax为最大在线KT节点数,a 为Nmin到Nmax平滑变动的加速度
Sn 为任一节点储存整体数据所占
则:
    C*x = Nmin*Sn*t+(a*Sn*t*t)/2
    x 为一天之内最多可以存在的整体数据复本数量
    需要如何描述和分配这个Sn 的内容和棵粒度?
    Sn为多少可以保证在一天的任意时段 x > 5,并最合理,可以保证前一算式成立?
    a 的极限最小是多少?
    Nmin 的权限最小是多少?
    在x=5时, Sn Nmin 最小是多少?

KT实现难点

  1. 分布式储存的控制和查询
    • 任务成果作为独立的文件对象,在流转,增加过程中永远可访问?
    • 查询的快速和下载/同步的快速,如何实现?
    • 信息扩散的优先级别动判定,保证所有任务信息,永远可访问!
  2. Bt的种子式数据同步
    • KT_mother 永远以Bt 方法尝试下载/更新所有任务成果
    • KT_sister 以Bt 方式下载想要的任务成果
    • 所有KT 自动以最小资源占用方式Bt下载/更新 任务索引 DB

PyKt/2006-01-05 (last edited 2009-12-25 07:10:05 by localhost)