月度归档:2014年07月

.NET技术+25台服务器怎样支撑世界第54大网站

http://www.csdn.net/article/2014-07-22/2820774-stackoverflow-update-560m-pageviews-a-month-25-servers

摘要:同时使用Linux和Windows平台产品,大量使用静态的方法和类,Stack Overflow是个重度性能控。同时,取代横向扩展,他们坚持着纵向扩展思路,因为“硬件永远比程序员便宜”。

【编者按】StackOverflow是一个IT技术问答网站,用户可以在网站上提交和回答问题。当下的StackOverflow已拥有400万个用户,4000万个回答,月PV5.6亿,世界排行第54。然而值得关注的是,支撑他们网站的全部服务器只有25台,并且都保持着非常低的资源使用率,这是一场高有效性、负载均衡、缓存、数据库、搜索及高效代码上的较量。近日,High Scalability创始人Todd Hoff根据Marco Cecconi的演讲视频“ The architecture of StackOverflow”以及Nick Craver的博文“ What it takes to run Stack Overflow”总结了StackOverflow的成功原因。


免费订阅“CSDN大数据”微信公众号,实时了解最新的大数据进展!

CSDN大数据,专注大数据资讯、技术和经验的分享和讨论,提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、机器学习、智能算法等相关大数据观点,大数据技术,大数据平台,大数据实践,大数据产业资讯等服务。


以下为译文

意料之中,也是意料之外,Stack Overflow仍然重度使用着微软的产品。他们认为既然微软的基础设施可以满足需求,又足够便宜,那么没有什么理由去做根本上的改变。而在需要的地方,他们同样使用了Linux。究其根本,一切都是为了性能。

另一个值得关注的地方是,Stack Overflow仍然使用着纵向扩展策略,没有使用云。他们使用了384GB的内存和2TB的SSD来支撑SQL Servers,如果使用AWS的话,花费可想而知。没有使用云的另一个原因是Stack Overflow认为云会一定程度上的降低性能,同时也会给优化和排查系统问题增加难度。此外,他们的架构也并不需要横向扩展。峰值期间是横向扩展的杀手级应用场景,然而他们有着丰富的系统调整经验去应对。该公司仍然坚持着Jeff Atwood的名言——硬件永远比程序员便宜。

Marco Ceccon曾提到,在谈及系统时,有一件事情必须首先弄明白——需要解决问题的类型。首先,从简单方面着手,StackExchange究竟是用来做什么的——首先是一些主题,然后围绕这些主题建立社区,最后就形成了这个令人敬佩的问答网站。

其次则是规模相关。StackExchange在飞速增长,需要处理大量的数据传输,那么这些都是如何完成的,特别是只使用了25台服务器,下面一起追根揭底:

状态

 

  • StackExchange拥有110个站点,以每个月3到4个的速度增长。
  • 400万用户
  • 800万问题
  • 4000万答案
  • 世界排名54位
  • 每年增长100%
  • 月PV 5.6亿万
  • 大多数工作日期间峰值为2600到3000请求每秒,作为一个编程相关网站,一般情况下工作日的请求都会高于周末
  • 25台服务器
  • SSD中储存了2TB的SQL数据
  • 每个web server都配置了2个320G的SSD,使用RAID 1
  • 每个ElasticSearch主机都配备了300GB的机械硬盘,同时也使用了SSD
  • Stack Overflow的读写比是40:60
  • DB Server的平均CPU利用率是10%
  • 11个web server,使用IIS
  • 2个负载均衡器,1个活跃,使用HAProxy
  • 4个活跃的数据库节点,使用MS SQL
  • 3台实现了tag engine的应用程序服务器,所有搜索都通过tag
  • 3台服务器通过ElasticSearch做搜索
  • 2台使用了Redis的服务器支撑分布式缓存和消息
  • 2台Networks(Nexus 5596 + Fabric Extenders)
  • 2 Cisco 5525-X ASAs
  • 2 Cisco 3945 Routers
  • 主要服务Stack Exchange API的2个只读SQL Servers
  • VM用于部署、域控制器、监控、运维数据库等场合

 

平台

 

  • ElasticSearch
  • Redis
  • HAProxy
  • MS SQL
  • Opserver
  • TeamCity
  • Jil——Fast .NET JSON Serializer,建立在Sigil之上
  • Dapper——微型的ORM

 

UI

 

  • UI拥有一个信息收件箱,用于新徽章获得、用户发送信息、重大事件发生时的信息收取,使用WebSockets实现,并通过Redis支撑。
  • 搜索箱通过 ElasticSearch 实现,使用了一个REST接口。
  • 因为用户提出问题的频率很高,因此很难显示最新问题,每秒都会有新的问题产生,从而这里需要开发一个关注用户行为模式的算法,只给用户显示感兴趣的问题。它使用了基于Tag的复杂查询,这也是开发独立Tag Engine的原因。
  • 服务器端模板用于生成页面。

 

服务器

 

  • 25台服务器并没有满载,CPU使用率并不高,单计算SO(Stack Overflow)只需要5台服务器。
  • 数据库服务器资源利用率在10%左右,除下执行备份时。
  • 为什么会这么低?因为数据库服务器足足拥有384GB内存,同时web server的CPU利用率也只有10%-15%。
  • 纵向扩展还没有遇到瓶颈。通常情况下,如此流量使用横向扩展大约需要100到300台服务器。
  • 简单的系统。基于.Net,只用了9个项目,其他系统可能需要100个。之所以使用这么少系统是为了追求极限的编译速度,这点需要从系统开始时就进行规划,每台服务器的编译时间大约是10秒。
  • 11万行代码,对比流量来说非常少。
  • 使用这种极简的方式主要基于几个原因。首先,不需要太多测试,因为Meta.stackoverflow本来就是一个问题和bug讨论社区。其次,Meta.stackoverflow还是一个软件的测试网站,如果用户发现问题的话,往往会提出并给予解决方案。
  • 纽约数据中心使用的是Windows 2012,已经向2012 R2升级(Oregon已经完成了升级),Linux系统使用的是Centos 6.4。

 

SSD

 

  • 默认使用的是Intel 330(Web层等)
  • Intel 520用于中间层写入,比如Elastic Search
  • 数据层使用Intel 710和S3700
  • 系统同时使用了RAID 1和RAID 10(任何4+以上的磁盘都使用RAID 10)。不畏惧故障发生,即使生产环境中使用了上千块2.5英寸SSD,还没碰到过一块失败的情景。每个模型都使用了1个以上的备件,多个磁盘发生故障的情景不在考虑之中。
  • ElasticSearch在SSD上表现的异常出色,因为SO writes/re-indexes的操作非常频繁。
  • SSD改变了搜索的使用方式。因为锁的问题,Luncene.net并不能支撑SO的并发负载,因此他们转向了ElasticSearch。在全SSD环境下,并不需要围绕Binary Reader建立锁。

 

高可用性

 

  • 异地备份——主数据中心位于纽约,备份数据中心在Oregon。
  • Redis有两个从节点,SQL有2个备份,Tag Engine有3个节点,elastic有3个节点,冗余一切,并在两个数据中心同时存在。
  • Nginx是用于SSL,终止SSL时转换使用HAProxy。
  • 并不是主从所有,一些临时的数据只会放到缓存中
  • 所有HTTP流量发送只占总流量的77%,还存在Oregon数据中心的备份及一些其他的VPN流量。这些流量主要由SQL和Redis备份产生。

 

数据库

 

  • MS SQL Server
  • Stack Exchange为每个网站都设置了数据库,因此Stack Overflow有一个、Server Fault有一个,以此类推。
  • 在纽约的主数据中心,每个集群通常都使用1主和1只读备份的配置,同时还会在Oregon数据中心也设置一个备份。如果是运行的是Oregon集群,那么两个在纽约数据中心的备份都会是只读和同步的。
  • 为其他内容准备的数据库。这里还存在一个“网络范围”的数据库,用于储存登陆凭证和聚合数据(大部分是stackexchange.com用户文件或者API)。
  • Careers Stack Overflow、stackexchange.com和Area 51等都拥有自己独立的数据库模式。
  • 模式的变化需要同时提供给所有站点的数据库,它们需要向下兼容,举个例子,如果需要重命名一个列,那么将非常麻烦,这里需要进行多个操作:增加一个新列,添加作用在两个列上的代码,给新列写数据,改变代码让新列有效,移除旧列。
  • 并不需要分片,所有事情通过索引来解决,而且数据体积也没那么大。如果有filtered indexes需求,那么为什么不更高效的进行?常见模式只在DeletionDate = Null上做索引,其他则通过为枚举指定类型。每项votes都设置了1个表,比如一张表给post votes,1张表给comment votes。大部分的页面都可以实时渲染,只为匿名用户缓存,因此,不存在缓存更新,只有重查询。
  • Scores是非规范化的,因此需要经常查询。它只包含IDs和dates,post votes表格当下大约有56454478行,使用索引,大部分的查询都可以在数毫秒内完成。
  • Tag Engine是完全独立的,这就意味着核心功能并不依赖任何外部应用程序。它是一个巨大的内存结构数组结构,专为SO用例优化,并为重负载组合进行预计算。Tag Engine是个简单的windows服务,冗余的运行在多个主机上。CPU使用率基本上保持在2-5%,3个主机专门用于冗余,不负责任何负载。如果所有主机同时发生故障,网络服务器将把Tag Engine加载到内存中持续运行。
  • 关于Dapper无编译器校验查询与传统ORM的对比。使用编译器有很多好处,但在运行时仍然会存在fundamental disconnect问题。同时更重要的是,由于生成nasty SQL,通常情况还需要去寻找原始代码,而Query Hint和parameterization控制等能力的缺乏更让查询优化变得复杂。

 

编码

 

  • 流程

 

 

  • 大部分程序员都是远程工作,自己选择编码地点
  • 编译非常快
  • 然后运行少量的测试
  • 一旦编译成功,代码即转移至开发交付准备服务器
  • 通过功能开关隐藏新功能
  • 在相同硬件上作为其他站点测试运行
  • 然后转移至Meta.stackoverflow测试,每天有上千个程序员在使用,一个很好的测试环境
  • 如果通过则上线,在更广大的社区进行测试

 

 

  • 大量使用静态类和方法,为了更简单及更好的性能
  • 编码过程非常简单,因为复杂的部分被打包到库里,这些库被开源和维护。.Net 项目数量很低,因为使用了社区共享的部分代码。
  • 开发者同时使用2到3个显示器,多个屏幕可以显著提高生产效率。

 

缓存

 

  • 缓存一切
  • 5个等级的缓存
  • 1级是网络级缓存,缓存在浏览器、CDN以及代理服务器中。
  • 2级由.Net框架 HttpRuntime.Cache完成,在每台服务器的内存中。
  • 3级Redis,分布式内存键值存储,在多个支撑同一个站点的服务器上共享缓存项。
  • 4级SQL Server Cache,整个数据库,所有数据都被放到内存中。
  • 5级SSD。通常只在SQL Server预热后才生效。
  • 举个例子,每个帮助页面都进行了缓存,访问一个页面的代码非常简单:

 

 

  • 使用了静态的方法和类。从OOP角度来看确实很糟,但是非常快并有利于简洁编码。
  • 缓存由Redis和Dapper支撑,一个微型ORM

 

 

  • 为了解决垃圾收集问题,模板中1个类只使用1个副本,被建立和保存在缓存中。监测一切,包括GC操。据统计显示,间接层增加GC压力达到了某个程度时会显著的降低性能。
  • CDN Hit 。鉴于查询字符串基于文件内容进行哈希,只在有新建立时才会被再次取出。每天3000万到5000万Hit,带宽大约为300GB到600GB。
  • CDN不是用来应对CPU或I/O负载,而是帮助用户更快的获得答案

 

部署

 

  • 每天5次部署,不去建立过大的应用。主要因为

 

 

  • 可以直接的监视性能
  • 尽可能最小化建立,可以工作才是重点

 

 

  • 产品建立后再通过强大的脚本拷贝到各个网页层,每个服务器的步骤是:

 

 

  • 通过POST通知HAProxy下架某台服务器
  • 延迟IIS结束现有请求(大约5秒)
  • 停止网站(通过同一个PSSession结束所有下游)
  • Robocopy文件
  • 开启网站
  • 通过另一个POST做HAProxy Re-enable

 

 

  • 几乎所有部署都是通过puppet或DSC,升级通常只是大幅度调整RAID阵列并通过PXE boot安装,这样做非常快速。

 

协作

 

  • 团队

 

 

  • SRE (System Reliability Engineering):5人
  • Core Dev(Q&A site)6-7人
  • Core Dev Mobile:6人
  • Careers团队专门负责SO Careers产品开发:7人

 

 

  • Devops和开发者结合的非常紧密
  • 团队间变化很大
  • 大部分员工远程工作
  • 办公室主要用于销售,Denver和London除外
  • 一切平等,些许偏向纽约工作者,因为面对面有助于工作交流,但是在线工作影响也并不大
  • 对比可以在同一个办公室办公,他们更偏向热爱产品及有才华的工程师,他们可以很好的衡量利弊
  • 许多人因为家庭而选择远程工作,纽约是不错,但是生活并不宽松
  • 办公室设立在曼哈顿,那是个人才的诞生地。数据中心不能太偏,因为经常会涉及升级
  • 打造一个强大团队,偏爱极客。早期的微软就聚集了大量极客,因此他们征服了整个世界
  • Stack Overflow社区也是个招聘的地点,他们在那寻找热爱编码、乐于助人及热爱交流的人才。

 

编制预算

 

  • 预算是项目的基础。钱只花在为新项目建立基础设施上,如此低利用率的 web server还是3年前数据中心建立时购入。

 

测试

 

  • 快速迭代和遗弃
  • 许多测试都是发布队伍完成的。开发拥有一个同样的SQL服务器,并且运行在相同的Web层,因此性能测试并不会糟糕。
  • 非常少的测试。Stack Overflow并没有进行太多的单元测试,因为他们使用了大量的静态代码,还有一个非常活跃的社区。
  • 基础设施改变。鉴于所有东西都有双份,所以每个旧配置都有备份,并使用了一个快速故障恢复机制。比如,keepalived可以在负载均衡器中快速回退。
  • 对比定期维护,他们更愿意依赖冗余系统。SQL备份用一个专门的服务器进行测试,只为了可以重存储。计划做每两个月一次的全数据中心故障恢复,或者使用完全只读的第二数据中心。
  • 每次新功能发布都做单元测试、集成测试盒UI测试,这就意味着可以预知输入的产品功能测试后就会推送到孵化网站,即meta.stackexchange(原meta.stackoverflow)。

 

监视/日志

 

  • 当下正在考虑使用http://logstash.net/做日志管理,目前使用了一个专门的服务将syslog UDP传输到SQL数据库中。网页中为计时添加header,这样就可以通过HAProxy来捕获并且融合到syslog传输中。
  • Opserver和Realog用于显示测量结果。Realog是一个日志展示系统,由Kyle Brandt和Matt Jibson使用Go建立。
  • 日志通过HAProxy负载均衡器借助syslog完成,而不是IIS,因为其功能比IIS更丰富。

 

关于云

 

  • 还是老生常谈,硬件永远比开发者和有效率的代码便宜。基于木桶效应,速度肯定受限于某个短板,现有的云服务基本上都存在容量和性能限制。
  • 如果从开始就使用云来建设SO说不定也会达到现在的水准。但毫无疑问的是,如果达到同样的性能,使用云的成本将远远高于自建数据中心。

 

性能至上

 

  • StackOverflow是个重度的性能控,主页加载的时间永远控制在50毫秒内,当下的响应时间是28毫秒。
  • 程序员热衷于降低页面加载时间以及提高用户体验。
  • 每个独立的网络提交都予以计时和记录,这种计量可以弄清楚提升性能需要修改的地方。
  • 如此低资源利用率的主要原因就是高效的代码。web server的CPU平均利用率在5%到15%之间,内存使用为15.5 GB,网络传输在20 Mb/s到40 Mb/s。SQL服务器的CPU使用率在5%到10%之间,内存使用是365GB,网络传输为100 Mb/s到200 Mb/s。这可以带来3个好处:给升级留下很大的空间;在严重错误发生时可以保持服务可用;在需要时可以快速回档。

 

学到的知识

1. 为什么使用MS产品的同时还使用Redis?什么好用用什么,不要做无必要的系统之争,比如C#在Windows机器上运行最好,我们使用IIS;Redis在*nix机器上可以得到充分发挥,我们使用*nix。

2. Overkill即策略。平常的利用率并不能代表什么,当某些特定的事情发生时,比如备份、重建等完全可以将资源使用拉满。

3. 坚固的SSD。所有数据库都建立在SSD之上,这样可以获得0延时。

4. 了解你的读写负载。

5. 高效的代码意味着更少的主机。只有新项目上线时才会因为特殊需求增加硬件,通常情况下是添加内存,但在此之外,高效的代码就意味着0硬件添加。所以经常只讨论两个问题:为存储增加新的SSD;为新项目增加硬件。

6. 不要害怕定制化。SO在Tag上使用复杂查询,因此专门开发了所需的Tag Engine。

7. 只做必须做的事情。之所以不需要测试是因为有一个活跃的社区支撑,比如,开发者不用担心出现“Square Wheel”效应,如果开发者可以制作一个更更轻量级的组件,那就替代吧。

8. 注重硬件知识,比如IL。一些代码使用IL而不是C#。聚焦SQL查询计划。使用web server的内存转储究竟做了些什么。探索,比如为什么一个split会产生2GB的垃圾。

9. 切勿官僚作风。总有一些新的工具是你需要的,比如,一个编辑器,新版本的Visual Studio,降低提升过程中的一切阻力。

10. 垃圾回收驱动编程。SO在减少垃圾回收成本上做了很多努力,跳过类似TDD的实践,避免抽象层,使用静态方法。虽然极端,但是确实打造出非常高效的代码。

11. 高效代码的价值远远超出你想象,它可以让硬件跑的更快,降低资源使用,切记让代码更容易被程序员理解。

原文链接: StackOverflow Update: 560M Pageviews A Month, 25 Servers, And It’s All About Performance(编译/仲浩 审校/魏伟)

java程序执行js脚本

public class ExecJs {

    /**
     * 记录日志类
     */
    private Logger log = Logger.getLogger(ExecJs.class);
    /**
     * 后置处理,执行js脚本
     * @param js
     * @throws Exception
     */
    public void execJs(String js, Map<String,Object> map) throws Exception {
        if (log.isDebugEnabled()) {
            log.debug("execJs js : " + js);
            Iterator<Entry<String, Object>> it = map.entrySet().iterator();
            while (it.hasNext()) {
                Entry<String, Object> entry = (Entry<String, Object>) it.next();
                log.info("EXECJS MAP : " + entry.getKey() + "---" + entry.getValue());
            }// end while
        }// end if
        if ("".equals(js) || js == null) {
            log.info("EXECJS ERROR : JAVASCRIPT CONTENT IS NULL");
        } else if(map == null || map.size()<=0){
            log.info("EXECJS ERROR : MAP CONTENT IS NULL");
        } else {
            // 获取脚本引擎
            ScriptEngineManager mgr = new ScriptEngineManager();
            ScriptEngine engine = mgr.getEngineByName("javascript");
            // 绑定数据
            ScriptContext newContext = new SimpleScriptContext();
            Bindings bind = newContext.getBindings(ScriptContext.ENGINE_SCOPE);
            bind.putAll(map);
            try {
                engine.setBindings(bind, ScriptContext.ENGINE_SCOPE);
                engine.eval(js);
            } catch (Exception e) {
                log.info("EXECJS EXCEPTION : EXECUTE JAVASCRIPT EXCEPTION", e);
                throw (e);
            }// end try
        }// end if
    }
}
调用例子
boolean flag = false;
String js = “var a = 1; var b = a + aKey;println(b);”;
Map<String,Object> map = new HashMap<String,Object>();
map.put(“aKey”, “aValue”);
try {
flag = execJs.execJs(js, map);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

安卓中如何实现无限滚动列表

列表和网格是安卓原生应用程序中使用最广泛的两个设计组件。开发者之所以大量使用它们,因为它们虽然实现起来简单明了,但提供了简洁、优良的用户体验。

使用列表和网格的一个基本要求是,当用户向下滚动时可以动态加载数据支持无限滚动。这篇博客将教你如何在自己的应用中实现这个特性。

我们需要的一个主要组件是InfiniteScrollListener类,它实现了OnScrollListener接口。让我们直接看下面这个类的代码实现:

InfiniteScrollListener.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
public abstract class InfiniteScrollListener implements AbsListView.OnScrollListener {
    private int bufferItemCount = 10;
    private int currentPage = 0;
    private int itemCount = 0;
    private boolean isLoading = true;
    public InfiniteScrollListener(int bufferItemCount) {
        this.bufferItemCount = bufferItemCount;
    }
    public abstract void loadMore(int page, int totalItemsCount);
    @Override
    public void onScrollStateChanged(AbsListView view, int scrollState) {
        // Do Nothing
    }
    @Override
    public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount, int totalItemCount)
    {
        if (totalItemCount < itemCount) {
            this.itemCount = totalItemCount;
            if (totalItemCount == 0) {
                this.isLoading = true; }
        }
        if (isLoading && (totalItemCount > itemCount)) {
            isLoading = false;
            itemCount = totalItemCount;
            currentPage++;
        }
        if (!isLoading && (totalItemCount - visibleItemCount)<=(firstVisibleItem + bufferItemCount)) {
            loadMore(currentPage + 1, totalItemCount);
            isLoading = true;
        }
    }
}

YourActivity.java

1
2
3
4
5
6
7
8
9
// Attach the listener to the AdapterView onCreate
yourListView.setOnScrollListener(new InfiniteScrollListener(5) {
    @Override
    public void loadMore(int page, int totalItemsCount) {
        List<HashMap<String, String>> newData = loader.loadData();
        dataList.addAll(newData);
        adapter.notifyDataSetChanged();
    }
});

如你所见,把这个类声明为抽象类。InfiniteScrollListener包含一个已实现的onScroll方法,但同时定义了一个抽象方法loadMore()——当我们继承这个类的时候需要实现该方法。

当用户滚动列表的时候,安卓运行时环境会自动调用onScroll方法。因为它会被频繁调用,所以建议避免在这个方法中做繁重的处理或者大量资源计算。

为实现无限滚动列表,我们仅需实现InfiniteScrollListener类,并使用ListView的setOnScrollListener()设置。我们可以用一个匿名类实现,就像上面第二段代码展示的那样。

在实现InfiniteScrollListener时,需要实现LoadMore方法。在此方法中我们可以生成想添加到列表中的新条目,然后使用我们适配器的notifyDataSetChanged方法添加上去。你可能要自己生成数据,也可以从数据库或者服务端加载。

这就是安卓中实现无限滚动列表所需要做的全部做工。列表是一种向用户批量展示信息同时又带来不错体验的方法。如果你的应用中已经有ListView或者你打算实现一个,下载我们的Native Ads SDK,它允许在你自己的列表中完全自定义广告。不过10分钟,在不影响用户体验的情况下,应用就可以为你赚更多的钱了。可以从这里检出代码。

17条千万流量的网站运营经验

为什么有的社区访问量能够突破千万,为什么社区活动一天的UV就高达100多万,参与活动的成员数量高达几十万,一次晒图就能引发数几万人参与,一个热门话题就能产生几千转发?

仅凭这些数据,尚不敢断言社区在移动端已经复兴,但这种过千万级的访问量和用户积极的参与程度在PC端的社区是从来没有过的。通过下文,让我们就来看看这些站长们是如何做到如上成绩的。本文由三名微社区运营者口述内容整理而成。

“当一个新产品诞生的时候,你是选择观望还是切身体验?我选择了后者。”——梦想海贼王
  
1、 基于强关系社交的产品,用户活跃度相对较高,但关键仍在于你如何利用它;

2、 有无固定用户资源决定了微社区定位,一类为内容运营,一类为客户运营;

3、 引导和培养用户使用习惯很重要,特别是对于客户服务类社区;

4、 充分利用标签等现有功能加之用户引导能起到事半功倍的效果;

5、 放权给管理员,一定要让他觉得这是自己的社区,充分发挥其能动性和影响力;

6、 设置菜单、推送图文,不放过每一个推广微社区的机会;

7、 不定期做活动绝对是社区运营的润滑剂。

起初,我是在一个行业网站上看到微社区这个产品的,但是我并不知道这个产品形态如何,价值何在。出于好奇,我开始在网络上搜索与微社区相关的各种报道。后来,我关注并体验了几个已经开通的微社区站点,第一感觉是它的内容展现形式和微博一样,发帖和回帖也基本类似,赞、收藏、分享等功能统统都有。当时我甚至想,这是要灭了微博的节奏啊?

微博用户活跃度已经开始下降,又是基于弱关系链,而微社区则依托于手Q和微信两大社交平台,如果运营的好,用户活跃度和参与的必然会高于弱关系社交。一开始我纠结于如何定义这个产品,从形式上看,它更像是手机版的论坛,但在体验上更为轻便。后来我发现微社区是什么不重要,叫啥也不重要,主要是看你怎么使用它,并让它为你或者你的用户创造价值。

总体来看微社区的运营者无非有两种,一种是没有自己的用户资源,想要借助微社区这一平台来获取这个平台上的用户,我对这类的运营者理解为内容运营。因为你要在一个平台上获取用户,你就需要取悦于他们,为他们提供喜欢的内容,例如:段子、图片、话题。另一种是有一定的用户资源,例如微信资源,使用微社区以解决多方交流屏障,增强用户互动。我对这类运营者理解为服务运营,通俗点叫客户运营,逼格点讲叫CRM。

我操盘的梦想海贼王微社区属于后者,服务运营,因为我们是手游,其次我们是一群有梦想的小伙伴,而且我们这群有梦想的小伙伴还有个共同的兴趣爱好那就是“海贼王”。我从最基础的社区搭建开始讲起。Logo、简介、信息这三块不需要太多技巧,简单明了,实事求是就好。标签我要重点说下,因为这是一个策略技巧问题,或许你可以重点利用别的地方:

由于我们入住微社区才两个月,而我们的游戏上线已经快一年了,所以用户习惯了去PC论坛和贴吧去发帖子、求助,虽然操作繁琐、复杂,他们也依然会这么做,那如果我们前期一开始就引导用户来微社区的肯定是另一份景象,因为微社区没有门槛,不需要注册账号,传东西,发东西更便捷,更高效,所以引导和培训用户习惯非常重要,特别是对于服务类运营。

一共有六个可以自定义的标签,我们开放了两个关于游戏类的使用,一个叫“游戏攻略”一个叫“互助问答”他们可以选择不同的标签,顾名思义根据标签内容发布,例如发攻略,再例发“互助问答”可以求助也可以回答别人的问题,对用户来说能高效的解决自己的疑难杂症,对我们来说前期引导好了,后期用户之间可以自助问答,缓解客服压力,节省人力,一举两得。

还有两个是“活动公告”“游戏吐槽”。这两个我一个是开放一个是关闭的,活动公告只有我自己才能用,游戏吐槽是给用户反馈意见,对游戏体验不满而设立的,每间隔一段时间我可以根据标签提取所有的问题反馈,这对一个游戏的研发和产品用户体验至关重要。在现有的功能下用好每一个小功能,再加以对用户的引导能起到事半功倍的效果。

我前面说了,因为我们有微信资源的优势,我只着重针对微信说一下我们是如何做好微社区前期推广的,我将这一阶段的工作称为“预热”。我们都知道,对男人来说美女是让他们致命的杀伤武器,对女人来说金钱是让她们冒险的动力。在推广微社区之前,我们就在微信预热,并开始招募美女管理员,这引起了一阵骚动。其次对美女管理设置了丰厚的钻石(游戏道具)奖励,然后各种写真集,爆照。

然后是“放权”。授权给这些通过投票产生的美女管理员,让她们帮我们打理、维护、运营微社区,一定要告诉她们这不是你的社区,而是她们的。钻石拉动女人,女人拉动男人,活动拉动大家,慢慢的就玩起来了。最后是“造星”。把美管捧起来,让她们有一定的影响力和粉丝群,我们的美管都有自己的粉丝,表白的更是数不胜数,自然有人会帮你哄这些美管们,有了福利和人捧她们会更热衷帮你打理社区。

预热工作做完之后,要设置微社区的入口。自定义菜单门槛比较高,需要认证的才可以,没有认证是不可以使用自定义菜单的,认证后只需要编辑模式添加菜单,把自己的微社区URL放上去即可。带锚文字的自定义回复格式如下,如果大家不会编辑这些把下面复制,替换自己想要输入的文字和自己微社区URL即可。

阅读原文是在你编辑单条、多条图文消息时,最下面原文链接那儿,把微社区URL放在那里即可,每次推送文章都是推广微社区的好办法。最后再加以文字引导,更方便用户清楚的发现,最好引导语也是你微信主题相关的,例如“我的新世界”就是海贼王剧情里的。

最后,进入真正的运营阶段。我总结出的经验是,不定期做活动绝对是运营的润滑剂。我们微社区做过各种各样的活动,下面拿两个典型的案例来跟大家分享下:

梦想海贼王微社区举办的两次活动

活动一:晒梦想大赛。我们的社区名字叫梦想海贼王,所以我们策划的活动也是跟我们有比较高的匹配度的,让人家一看就知道你的是要干嘛,说白了就是不要跑题,其次就是参与门槛低,一定要优化参与方式,减少参与步骤,一个能唤起大多数人共鸣的活动一定离不开好的策划。另外,我建议给你的活动来个牛逼哄哄的开场白。晒梦想活动大赛活动当天日PV最高10万+,参与人数五千。

活动二:路飞生日快乐。与时俱进,挖掘当下最热门的话题和内容,改编或者借鉴一下改成自己的。内容类运营找热门话题最简单了,但服务类运营的就不能随便发那些热门话题。但是一定是有话题可以挖掘的,例如刚刚赶上路飞生日,最近乌索普,明哥很火这都是热门话题,如果实在没话题你也可以制造点话题。

作为最早一批开通微社区的站点,我在这里也给新手两点建议。一是先关注一些其它优秀社区,它们一定积累了大量的经验,新手可以从它们身上学到很多宝贵经验,拿别人碰的头破血流,犯错误的经验来减少自己的犯错几率,通过对比找到自己的不足。二是积极参与线上线下各种活动和培训,千万不要自己瞎琢磨,要经常在群里跟大家交流,听大家在聊啥,遇到了什么问题,参与其中交换看法,也许你参加培训不一定能学到什么实用的经验,但是你肯定会碰到很多运营者同行他们会帮你拓宽思维。

“身为80后,刚开始上网的那几年,我每天花很多时间泡论坛,后来人人网、微博、微信渐渐流行,论坛就玩得少了。不知道微社区能否重现当年论坛的繁荣景象。”——十点读书

1、 利用微信、微博等多个渠道宣传并加以文字引导;

2、 征集话题,发布公告引导用户进入社区交流讨论;

3、 定期举办活动,以物质奖励提高用户发帖积极性;

4 一次好的活动增加百万访问量,方法比努力更重要;

5、 多与用户互动,使其成为你的忠实用户。

微博刚开始其实也有社区,叫微群。我那个时候也做了一个,刚开始挺热闹,陆续做到3万粉丝,但是后期活跃度越来越低,后来发现微群的团队自己也不太看重这个产品的运营,重点去做微吧,我也随之放弃了。

去年底,腾讯推出了微社区,我是微信端第一批内测用户,也是手机QQ端早期的用户之一。目前微信上访问量近700万,手机QQ上有7万9千多订阅者。在这里与大家分享一些推广和运营上的经验。

首先是推广。

先说微信平台。微社区开通之后用单图文宣传,告诉大家我的微社区如何进入,可以做什么,比如我当时介绍说大家可以在微社区发表对文章的看法,推荐大家喜欢的书,问题求助,爱读书的粉丝有了自己的社区家园等。 如果你认证了,有自定义菜单,那就在自定义菜单中加上微社区链接,这是最好、最有效果的办法。

另外,我在关注自动回复中加入微社区地址,粉丝一关注我微信就可以先进入微社区体验,我还设置了个自动回复“BBS”也可以进入社区,方便粉丝下次进入。每天都尽量在推送文章的底部“阅读原文”加上微社区地址,并且加一句话提醒,“欢迎点底部阅读原文进微社区交流讨论”。

再说微博平台。在微博上宣传,说微信号里开通了一个微社区,相当于bbs,大家加微信就可以进入讨论,交流读书心得。吸引一些粉丝关注微信,来体验微社区。 之后,手机QQ也开始上线微社区,我开始在微博宣传,也在微信文末宣传,让大家上手机QQ上关注我的微社区,订阅用户当时排在所有微社区的前几名。

打开微社区,右上角有个分享,你也可以分享给你的微信QQ好友,也可以分享到微信QQ群,让大家加入微社区。

其次是内容。

引导用户发一些合适的交流、分享、求助的帖子,禁止广告等,可以写一个公告说明。平时在微信征集一些话题,让大家去微社区讨论。比如过年的时候我征集了“说说故乡的那些人那些事”,有不少粉丝参与写感动人的帖子。

十点读书微社区举办的活动

定期做一些活动,比如我和出版社合作在微信做连载,注明看连载的时候到微社区发帖有机会获得赠书。这个时候读者发帖写读后感的积极性就很高。

最后是管理。

每天有空的时候在网页或手机上去管理,互动,删帖,多在一些帖子评论,用户如果看到站长评论会很高兴的,促使他经常来社区留言互动,成为忠实用户。如果看到广告就删帖,过分的直接禁言。

可以多邀请一些活跃的用户成为管理员。我的社区本来有2位管理员,有段时间社区广告比较多,都删不过来,后来又邀请了几位活跃用户成为管理员,他们在登陆的时候看到广告就会帮忙删除。

可以设置标签,每个标签相当于一个版块。我在手机QQ微社区上看到一个”英雄联盟”的微社区里面已经有版块了,主版块里还有很多分版块,总成员达到3千多万,后来得知他们是与微社区数据打通之后的PC社区,这一点让我不得不承认DZ在移动社区方面做出的努力。

身为80后,刚开始上网的那几年,我们每天花很长时间用来泡论坛,后来人人网、QQ空间、微博、微信渐渐流行,论坛玩得少了。希望在移动互联网时代,微社区能重新开启当年论坛的繁荣景象。

“我们不会过多限制用户发帖的主题,除了广告和使用不文明用语,基本不限制玩家发言,但是社区出现舆论危机时,如果影响比较大,一定会及时解决。”——开心水族箱

1、 以活动和奖励引导用户进入并使用微社区;

2、 留住用户的前提是找对用户的胃口,投其所好;

3、 点赞等投票性质的活动可以促使用户主动传播;

4、 将运营活动周期化、固定化是培养长期用户的好办法;

5、 不限制用户发言,与意见领袖保持良好的沟通和联系。

开心水族箱一直想寻找一个可以集合大部分游戏玩家的移动端社区,我们有贴吧、论坛、微博、微信,也做过多酷社区,但是依然缺乏一个可以集合大部分玩家的手机端轻社区。今天3月初我们开通了苹果版的微社区,4月开通了安卓版微社区,如今这两个社区已经成为游戏最重要最活跃的社区,是玩家互动交友、举办活动和收集意见反馈的重要渠道。

引导用户进入并使用微社区
  
微社区刚开张时为了全方面引导玩家进入微社区,不光靠微信推送消息,我们也在微博贴吧全面发力,游戏内悬挂公告,配合以大力度的活动——萌鱼表情模仿秀,以真人秀+游戏IP结合这种玩家感兴趣的形式,并以游戏内当期热门的奖励,来引导玩家参与。

在安卓社区,因为已经有了苹果社区的认知基础,我们在玩家中预热做了一场盛大的抢楼活动,抢一楼,前五十楼,前一百五十楼都可以获得各种不同档次奖励。这个活动直接让社区在玩家中一炮而红。

引导还体现在引导玩家发高质量的帖子,我们的游戏有很多玩家互动的地方,也有分享攻略的需求,我们会通过嘉奖发攻略、分享、互助帖帮助其他玩家的用户培养用户爱发言爱分享的习惯。久而久之会有更多人分享,更多人来看。
  
发掘用户感兴趣的话题

用户来了之后就要想办法留住他们,发掘对玩家胃口的话题就很重要。我们的游戏是一款轻度休闲游戏,大部分玩家都是20-30岁之间的女性,很多是带着孩子的妈妈,他们有别于互联网上比较主流的那批用户,因此我们做活动都特别针对玩家的喜好进行考虑。比如妈妈都喜欢晒孩子,我们做过2次让玩家和游戏里小鱼的比萌大赛,效果都不错,还有各种追忆青春少女时光等情感向活动。

开心水族箱微社区举办的活动

除了大型活动以外,我们也会利用热门话题、小互动等等来吸引人气。比如在感恩节我们配合游戏活动做了看图猜蛋的互动,GM在感恩节彩蛋上画游戏里的鱼,在社区发帖让玩家来猜画的是哪条鱼,第一个猜对的可获得奖励,这个活动反响不错,相信未来还有更多好玩有趣的互动有待发掘。

促使用户主动传播

点赞活动是我们常用的一种方式,因为我们发现部分参与活动的玩家会把自己的帖子发到玩家群、贴吧等其他社区或直接发给好友让其为自己点赞,这种行为也很好的传播了我们的社区,因此点赞活动是我们常用的活动方式。

常做的点赞活动有图片点赞、作诗点赞,还有拼四格漫画等等。此外还会在游戏内页结合微社区做传播向活动——例如“装扮我的小布偶”即是让玩家装扮布偶,完成最后一步装扮后需要把自己做的独一无二的布偶发到微社区才可以领取奖励,这种方式让社区多了许多高质量UGC内容。

培养用户访问社区的习惯

要让用户形成访问社区的习惯,就要定期举行活动,并且让社区成为用户获取信息的重要渠道,我们时常会把游戏里还没出的新鱼、新活动预告放在社区,或者做个互动小活动,一般玩家对于新的东西兴趣都是最高的,因此就会很愿意参加。

总之用户能在这里获得想要的东西并且能在这个过程中获得快乐,持续感受到游戏的乐趣,并且能和一群兴趣相投的鱼友一起互动,这就是我们运营的宗旨和核心。把运营内容周期化、固定化不失为一个好方法,例如定期奖励活跃用户,定期举行主题活动,定期做互动,这种习惯的培养对于培养长期用户比较有帮助。

社区氛围的形成
  
我们不会过多限制玩家的主题,除了广告和使用不文明用语,基本不限制玩家发言,但是社区出现舆论危机时,如果影响比较大,一定会及时解决。社区的氛围受游戏里的情况影响比较深,因此风向有时候是很不确定的,在做社区时平时就要和很多意见领袖型用户保持好的沟通和联系,让他们帮忙引导社区的舆论和气氛,及时举报不良信息,健康的社区需要引导和管理,我们正在培养形成互动有爱的玩家社区这个目标上继续努力。

原文来自:iheima   作者:郝小亮