zoukankan      html  css  js  c++  java
  • 尝试分析Q群作为技术群是个不恰当的选择!

    前言

      其实,混过技术群的朋友,都会有个这样的体验,这压根就是闲聊的嘛,当然,有些管理严格的群是真正的在讨论技术,但是,如果把Q群作为技术讨论的工具,是先天性的不适合.可是,却被大家广泛的使用

    信息的健壮性

      作为,技术讨论,最重要的当然是发起一个能个引起大家讨论的话题,例如,有一个朋友在Q群里发送了一个消息.

    q1

    我们,应该都知道QQ是以广播(UDP)的方式,来对我们消息进行广播,然后,就出现下图所示的情况

    q

    我这里假设的是一个有着100个人的Q群,从图中我们看出,我们发出的一条消息,我们并不知道,是否所有的人都收到了(以UDP协议发送的消息是没有回执的),而现实也是这样,有些人没上线就自然错过了,有些了虽然看起来在线,实际上已经屏蔽了群信息,这样的话,就会可能让很多人错过了,本来感兴趣的话题,但是却错过了.

    接着,你发布了第二条消息

    q

    而这一次,可能A因为,某种原因没收到,而这次Z确收到了(可是,我们却不知道,但是,却实际存在),这样的后果就是,我们原本完整的消息破碎了.没有了进行讨论下去的内容上下的语境

    从这里我们就可以看出,Q群的消息传播是不稳定的.也从而导致,消息的破碎,而无法进行讨论.

    信息的可维护性

    假设,我发布了一个消息,A朋友,和B朋友对此都很感兴趣,对于消息1,A朋友做出,A->消息1问题的看法,B朋友做出,B->消息1问题的看法

    q2

    这下,我们得头疼了,我们,该维护谁对消息的看法呢?在Q群中的消息是属于一种栈结构,而且每次只能存放一种消息,如果是一对一的讨论这种结构就没有如何问题,如果是一对多的话,这种结构就是先天性的不适合.更麻烦的还在后头…

    接下来,你对A朋友的消息看法做出回答,发出消息2,但是,你却没注明,这时,你这个消息2让A朋友,B朋友接受到了,而此时,Z朋友刚好上线,看到了消息2,对于消息2表示感兴趣,作出只对于消息2的看法.而由于,不知名原因,C朋友只获得了消息1的信息(前面的一些信息确没了,这个时常发生!!),而刚好,C朋友又对消息1有兴趣,做出了C –> 消息1看法,

    这下你该头痛怎么维护你的消息了..

    1,维护消息1 –> 维护消息2 (红线,对于A朋友,B朋友的回答)

    2,维护消息2 (蓝线,对于Z朋友的回答)

    3,维护消息1 (绿线,对于C朋友的回答)

    无论选择那一种,都已经无法维护消息了.

    q3

    这个图示还算比较简单的模式了,还有更复杂的情况就留待大家去想了,从这里我们可以看出,Q群对于一个多元的消息的维护性基本为零…

    Q群如果作为技术讨论而言基本上无法对消息进行维护.

    信息的持久化

    如果,以上两点,可以通过管理而进行完善的话,那么这第三点就是,就是Q群的硬伤了,那就是消息的存储,我们都知道,我们对于Q群的消息有个叫做消息记录的东西,但是,这个消息记录保存的消息基本上是不完整的,当然,对于QQ会员有一个叫做离线消息记录的服务.可是,就算有这个,你也无法保证你的消息获取是完整的,这一点,在第一节中就有过讨论.无法,对消息的进行可持久化,最不好的一点就是,无法将消息的价值最大化.很典型的一个场景,新朋友Q,加入进来Q群,发出某个话题的讨论,可是这个话题的讨论却在很久以前就讨论过了,但是,没有保存下来,接着,要不就重复,要不就是没人搭理

    可替代品?

    针对以上三点,有人尝试通过使用Q群自带的论坛进行修正,但是,基于BBS结构都论坛模式,也有其存在的硬伤,就是BBS能作为深度讨论的工具很好,但是,对于,小型的讨论会而言,无疑BBS的实时性,和可通知性就没法保证,还有就是,BBS作为消息输入也比较麻烦.

    接下来就是使用google groups 即邮件组的模式,这个,国内受众人群较少,不知道现在什么情况,我身边的朋友,就很少人接触邮件组这个上世纪非常流行的模式.

    在接下来就是新浪推出的,微群服务,这个我正在研究中,以后有机会,在发一篇长文分析,个人感觉,进行小型讨论,微群的功能都基本能满足,不过,这点不好下定义,等实践玩以后再作定论.

  • 相关阅读:
    【数据库】事务,ACID,CAP和一致性
    线程,进程。多进程,多线程。并发,并行的区别
    mysql 集群 数据同步
    如何读取一个表的表类型,以及读取一个表中字段的类型.
    网络攻击技术开篇——SQL Injection
    MySQL数据库作发布系统的存储,一天五万条以上的增量,预计运维三年,怎么优化?
    程序员找工作那些事(一)幸存者偏差
    程序员
    preg_replace的一些细节
    HDU 1258 Sum It Up(dfs 巧妙去重)
  • 原文地址:https://www.cnblogs.com/youxilua/p/2346762.html
Copyright © 2011-2022 走看看