标题：javaeye
简介
JavaEye(现更名为ITEye)是在2003年9月创办的，缘起是创始人范凯自己在学习和研究java的开源框架却发现没有一个讨论的  javaeye技术网站地方，于是自己就办一个。如今，已经是国内专业性内容社区网站的佼佼者。 
经过几年的持续不断的开发和完善，JavaEye网站已经发展成为了一个内容齐全，功能丰富的中文IT技术门户和社区网站。但是现在的JavaEye网站距离一个理想的智能化IT技术社区还有很大的差距，需要我们长期不懈的改进和完善。 
JavaEye是一个以讨论Java技术和Hibernate技术开始的技术论坛，已经成为一个涵盖整个软件开发领域的综合性网站，2005年被选为中国十佳技术网站之一，受到广大软件开发者的好评。
但是，2010年11月22日，国内知名Java编程网站JavaEye被关闭，访问网站被提示：“网站因有违规内容而被关闭，具体事宜请联系您的接入商”。JavaEye网站应该是在下午时间（1点10分左右）被关闭。截止当日晚间尚不知网站具体违规内容。网站域名没有跳转直接显示该内容，有部分网友质疑是被黑了。
创始人范凯在微博中称：JavaEye被封是因为写的动态防火墙代码太智能，把电信负责内容监控的爬虫给封了，导致被封。把监控爬虫加入白名单了，争取下午恢复网站访问。并非由于是网站含有违法内容导致。
据此前消息，JavaEye已被CSDN收购，不过CSDN 和JavaEye 均未对此事发表任何说明，收购的细节也无从得知。
网站介绍
CSDN(创新乐知)是一家服务于中国IT专业人士学习与成长需要的领先综合社区服务平台。CSDN以旗下  javaeye技术网站全球知名中文IT技术社区为基础，通过网站·杂志、教育·培训、人才·交易三大业务群形成从知识传播、技术教育到职业成长的完整知识传播与服务链。 　JavaEye是一个软件开发人员的深度交流社区。JavaEye创建于2003年9月9日，JavaEye一直致力于为中国的软件开发人员提供一个良好的有深度交流的社区。 JavaEye是一个以讨论Java技术和Hibernate技术开始的技术论坛，现在已经成为一个涵盖整个软件开发领域的综合性网站，2005年被选为中国十佳技术网站之一，受到广大软件开发者的好评。[1]
开发计划
JavaEye网站2010年的开发计划将分为三个阶段来进行：第一阶段全面完善网站各个频道的功能、根据全站内容分类推出个性化的定制内容，强化个人消息输出功能，改进网  javaeye技术站开放API等等。
1、根据全站内容分类推出垂直频道，以及根据用户兴趣，推出个性化定制门户 
JavaEye从2009年开始就一直悄悄的不停改版和底层内容的打通，通过新闻频道改版，问答频道改进，专栏频道改版，博客频道改版，圈子频道改版，以及新推出的文摘频道，进行全站所有频道和所有内容的统一分类，这个工作现在已经完成了。大家可以注意到频道左侧的两级内容分类导航，现在无论是新闻文章，论坛帖子，博客还是提问，抑或圈子讨论和专栏文章都被归类到某一个分类下面了。JavaEye网站的全站内容一级分类有20大类，和论坛的版面对应，内容二级分类有120小类，和论坛的tag也是对应的，因此根据任何一个大类或者小类，都可以立刻抓取出来该分类下面所属的任何网站内容，组装成为一个特定分类的垂直门户网站。 
这意味着，JavaEye可以立刻切分出来一百多个小网站，例如那些对Android感兴趣的开发人员，以后可以直接通过域名进入这个更加细分的垂直社区，JavaEye全站所有关于Android的内容可以尽在掌握了。 
更进一步，有了详细的内容分类，我们可以给用户提供定制化功能，让用户挑选自己感兴趣的内容组装成个人门户，例如用户关心Ruby，Python和iPhone方面的内容，那么用户挑选Ruby和Python一级分类和iPhone二级分类，然后就可以通过我的应用进入个性化门户，其他所有无关内容全部过滤，只订阅和浏览自己感兴趣的内容，是不是很酷。
2、改进网站的全文检索，提供动态的内容分类和提取，实现任意热门内容的垂直门户 
全站内容分类还不够灵活，但是有了内容分类作为训练材料，我们可以更好的改进全文检索，从全站所有内容当中迅速提取出来热门内容，组装一个垂直门户网站出来。
例如最近云计算很热门，但是云计算涉及很多跨分类的技术，可能涉及互联网，web前端，移动编程，企业应用等很多领域，用户发表文章也往往根据自己用到的技术门类去发表，因此JavaEye没有办法专门为了云计算开分类或者版面。但是有了更加强大的全文检索，结合全站内容分类，我们可以瞬间从全站内容当中提取所有和云计算相关的内容，组装一个的垂直社区出来，是不是很爽？有了这种神器，BD厂商客户将变得易如反  javaeye聊天客户端掌！
3、PDF电子书下载频道 
早在2008年我们实现了博客电子书功能的时候，就设想了要做电子书下载频道，如今全站内容分类全部做好，而且新闻频道，博客，专栏频道，文摘频道都已经全部支持制作PDF。接下来我们要做的就是提供各种频道分类，各种内容分类的PDF电子书下载频道了。这个下载频道可是绝对正版噢！另外我们也将有可能加大专栏内容的建设，为大家提供更多更好的技术专栏PDF下载。
4、网站内容的相关文章优化 
利用全文检索技术，JavaEye所有内容都有相关内容的推荐，无论新闻、论坛还是博客都有相关文章，我们将加强相关文章的推荐，更合理的提取和优化相关文章，提升页面的SEO效果。这将带来更多的SEO流量，以及更高的用户点击率。
5、招聘频道建设好企业会员服务 
招聘频道在2009年也进行了彻底的改版，如今我们已经实现了对招聘信息的分类广告投放功能，例如一个Android程序员的招聘信息，我们可以精确的投放到全站任何出现Android分类的文章，比方说Android新闻，Android博客，Android讨论等等，当然这也得益于全站内容分类的前期工作。在有了这些强大功能的基础之上，我们会专门为企业会员开发和提供更多更好的服务，争取做好专业技术领域的在线人才服务。 
6、改进和优化个人应用的各项服务 
目前JavaEye网站所有内容都是对匿名用户公开的，所以注册会员访问比例远低于匿名会员访问比例。个人应用是2009年初推出的针对注册登录用户的个性化服务，但是一直没有正式发布和推广，个人应用的各项功能和界面也一直没有进行改进，在解决上述问题之后，我们将重点建设和推广个人应用，力争将网站的注册会员访问比例提高5-10%。 
此外，还计划改进JavaEye OpenAPI，重写和升级Firefox插件，推广Android客户端，力争将个人应用功能激活，让更多会员即使不上JavaEye，仍然可以随时随地访问JavaEye的数据。 
第一阶段计划用2－3个月的时间来完成。
第二阶段：使用MongoDB详细记录网站的每个访问请求，研发网站用户行为跟踪和分析系统 
专业网站的用户规模永远不可能超越大众网站，但是专业网站的价值在于精准定位的高端的用户群体。尽管行业厂商很多还习惯于粗放型的首页Banner广告，但是更多厂商已经把目光转移到精准的用户营销上来了。厂商更加关心的是自身产品的实际到达率是什么，究竟有哪些用户在关注他们的产品，对他们的产品的评价是什么，哪些用户可能成为潜在的客户，这些用户都是什么行业，什么收入水平等等。
所有的这些精准用户营销需求现在没有一个网站可以满足，而这正是JavaEye想做到的功能。Jav  javaeye技术网站aEye通过内容分类，通过用户资料、用户发帖和用户定制内容，还加上用户访问JavaEye的所有轨迹，点击了哪些帖子，经常访问哪种类型的内容，关注了哪些用户等等信息，有望对用户身份进行精准的识别。分析出来用户从事什么行业，职位高低，收入水平，技术水准，对哪些领域的产品和技术感兴趣等等。
有了精准的用户识别，我们可以为厂商提供ROI最好的媒体服务，甚至是可以及时得到用户的反馈，例如SOA厂商的新产品，如果乱打广告，可能很多人骂，但是如果把这些产品信息精准的推荐给那些真正正在从事SOA领域开发的顾问和专家，那么广告本身就是有价值的，他们会感兴趣的信息。并且还可以立刻得到用户对产品的反馈和评价，而这些反馈和评价都是来自真实的行业专家，对厂商的价值不言而喻。精准的营销对网站用户也会带来更好的用户体验，因为带干扰性的通栏广告更少了，而那些精准的产品推荐刚好是用户正在关注或者正希望去了解的信息。
但是要研发这样一个用户行为跟踪和分析系统，在技术上有很大的挑战性，一方面我们需要新的NoSQLDB技术引入，例如用MongoDB存储和分析海量的用户访问记录；另一方面需要用全文检索对海量信息进行分析和提取，此外还需要设计良好的公式评价系统和降低噪音的功能。不过由于JavaEye已经对全站内容进行了统一的分类，因此在用户识别和内容识别方面难度会降低很多。如果说有一个网站能够率先做到这一点的话，肯定非JavaEye莫属了。第二阶段预计需要2-3个月时间来开发和实现。第三阶段基于真实用户关系的SNS 
从2007年就开始关注SNS，08年对SNS写了很多文章下了很多论断，现在看来都一一验证了。一个以内容为核心的社区，特别是专业性质的行业社区是不适合直接用SNS的，这也是为什么JavaEye迟迟不做SNS的原因。JavaEye的研发重点还是应该放在加强内容核心这一点上，因此在过去的两年当中，我们的研发全部放在了全站内容分类上。但在做好和加强内容核心的基础之上，SNS的需求仍然挥之不去，因此如果我们能够顺利实现前面两个阶段的工作，将尝试开发和运营SNS。 
JavaEye的SNS需求针对的用户群体是什么？ 
1、一些软件公司的整个研发部门都上JavaEye，同事之间的交流需求 
2、一些通过JavaEye认识，见过面的朋友，他们之间的在线交流 
3、同一个学校同学们毕业以后在JavaEye上的在线交流 
交流的方式应该不是发帖，也不应该是social game，具体什么样的交流方式我还没有想得很清楚，但是感觉上必须符合如下的条件：
1、必须是实名注册的用户，才开放SNS。实名注册，和真实的用户关系（生活当中认识的人）很重要。如果不满足这两个条件，就根本没有必要用SNS。JavaEye现有的服务都可以满足了。
2、不必提供内容交流功能，现在的JavaEye在内容交流方面已经做到的极致；但也不能做social game，否则JavaEye会被软件公司封杀。应该是一些轻量级的交互性展示和评价：例如用户的个人履历（非简历），生活近况，对同事同学的评价，工作上的互相推荐和交流。应该有点类似linkedin，但不能那么死板。
总之还需要大家多提建议，集思广益。如果能够做一个很成功的SNS出来的话，对JavaEye本身和用户都有很多益处。例如对网站来说，用户规模更大，用户活跃度更高，基于用户识别的精准的营销和人才服务都将更加准确，猎头服务做起来就很容易了。而对于用户来说，可以加强和同事，同学，朋友之间的技术和生活交流。
第三阶段希望下半年开始摸索着去尝试，在年底能够小有成绩。展望2010年，JavaEye要做的事情还是很多的，希望年终可以按计划顺利实现目标，完成计划就是胜利。 
产品特色
一、满足极高读写性能需求的Key-Value数据库：Redis，Tokyo Cabinet， Flare 
高性能Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis，Tokyo Cabinet， Flare，这3个Key-Value DB都是用C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的功能：
1、Redis 
Redis是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是我知道的性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，例如从List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github，Engine Yard。 
2、Tokyo Cabinet和Tokoy Tyrant 
TC和TT的开发者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS网站上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理4-5万次读写操作。 
TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一，有一个Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。
TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的NoSQL数据库。 
TC的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降，NoSQL: If Only It Was That Easy提到，他们发现在TC里面插入1.6亿条2-20KB数据的时候，写入性能开始急剧下降。看来是当数据量上亿条的时候，TC性能开始大幅度下降，从TC作者自己提供的mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考 
3. Flare 
TC是日本第一大SNS网站mixi开发的，而Flare是日本第二大SNS网站开发的，有意思吧。Flare简单的说就是给TC添加了scale功能。他替换掉了TT部分，自己另外给TC写了网络服务器，Flare的主要特点就是支持scale能力，他在网络服务端之前添加了一个node server，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。如果你的使用场景必须要让TC可以scale，那么可以考虑flare。 
flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的key-value数据结构存储。 
二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB 
面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。MongoDB是用C++开发的，而CouchDB则是Erlang开发的： 
1. MongoDB 
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。 
Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。对于Mongo的并发读写性能，我（robbin）也打算有空的时候好好测试一下。 
因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。 
最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用，比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著的提升。
MongoDB也有一个ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大易用。
2. CouchDB 
CouchDB现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。 
三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort 
面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的： 
1. Cassandra 
Cassandra项目是Facebook在2008年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而开源出来的Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了Facebook之外，twitter都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。
Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra，有非常详细的介绍。
Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。 
2. Voldemort 
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读写性能也很不错，每秒超过了1.5万次读写。 
从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库，特别是对数据库的scale能力方面的需求是多么殷切。前面我（robbin）提到，web应用的架构当中，web层和app层相对来说都很容易横向扩展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在Cassandra这么热门的主要原因。 
如今，NoSQL数据库是个令人很兴奋的领域，总是不断有新的技术新的产品冒出来，改变我们已经形成的固有的技术观念，我自己（robbin）稍微了解了一些，就感觉自己深深的沉迷进去了，可以说NoSQL数据库领域也是博大精深的。
运营经验
草根创业者的固执与执着：确立网站核心价值 
JavaEye是在2003年9月创办的，缘起是创始人范凯自己在学习和研究java的开源框架却发现没有一个讨论的地方，于是自己就办一个。如今，已经是国内专业性内容社区网站的佼佼者。范凯对于早期网站的运营描述为：一天10几个小时趴在自己的网站上玩，除了睡觉就是泡在BBS上。慢慢地人气就来了。 
但BBS各种弊病也不期而遇：跪求、裸求、留爪、接分、mark、标题党等。范凯抛给网站运营者们的第一个问题就是“什么才是网站的核心价值”。他反复在问自己“乌烟瘴气、八卦、互相攻击的气氛是我想要的吗？”范凯执着的认为自己要的就是一个深度交流技术、心平气和学习的地方。为了营造一个比较干净、安静交流技术的地方，从在2003年12月范凯开始采取比较严格的管理制度。这些管理制度大多数网站都有，但真正执行起来没几家没有比的上JavaEye。“其他站长害怕得罪用户，怕别人不来了。我不怕，我甚至不希望有这种没质量的流量，首先你要认同这种价值观才是 JavaEye的会员。”
JavaEye的新用户注册时需要强制做题。做13道有关论坛规则的选择题，做不对就不予审核通过。范凯举了个例子：有个用户看到一个帖很好，想回复，一点，要注册，注册就注册吧，要邮箱激活，激活就激活吧，然后呢，回来发帖，还不行，要做题，做对了题居然还不行，说新注册的用户要3天后才能发帖。于是这个用户把javaeye大骂一顿，说很不友好。 
对于javaEye来说，对于有序讨论的保证才是核心用户的最好用户体验。一个网站的核心价值的确立，就是问自己的内心：“你想做一个什么样的网站”，然后检视“这个网站对其他人来说有没有价值”。如果这两点都有了明确的答案，那么就记住这句话：走自己的路，让别人说去吧。许多朋友力劝、许多网友诅咒，请不为所动。请执着，不要再被别人影响了。 
专业型BBS的品牌树立：“良币驱逐劣币” 
2003年12月范凯决定实施严格的论坛管理制度，很多人质疑。但事实上，网站在2004年年初居然得到飞速发展，而且口碑一下就传开了。
虽然清洗了1万名非目标用户，却留住了100个核心用户。并且这100个核心用户产生的内容吸引了10万个会员。因为这100个用户是能创造大量有价值的内容，并且彼此有很好的互动。看似自杀的管理制度，其实带来了论坛的核心竞争力。BBS的魅力和缺陷都来自于“顶帖制度”。有最新回复的帖子就放在最上面，于是这些帖子会被更多人关注，获得更多评论，能很快把一个话题炒起来。可以说，BBS相比于SNS、博客、百度问答等更容易繁荣起来。回帖就像平等的投票权，新手和老用户一样有这个权利通过回帖把一个帖子顶到最前面。在网站运营初期，这种机制能快速帮助BBS聚集人气，达到用户互动的高潮。但是回复灌水和标题党也成了这种顶贴制度不可避免的产物。但这对于专业型 BBS来说很糟糕，会破坏专业性、高质量的讨论。
因此，BBS一般都会有一个相似的曲线：很快地崛起，会有一个很繁荣的时期；但是随着会员越来越多，核心用户就被稀释掉了；有信用度的老用户的很多权利得不到体现，便会出现“劣币驱逐良币”的效应；当核心用户都走光了，这个BBS就被新的BBS所替代，其自身就会面临消亡。 
对于JavaEye这个专用型BBS的严厉管理制则坚定地摈弃非目标用户，用核心用户吸引更多会员。除了上文提到的给新注册用户设下的考验，还可以举个例子如何吸引核心用户。在BBS，经常可以看到“跪求”、“弱弱的问”等重复的入门提问帖，但是这会让核心会员疲惫，所以范凯索性开了一个问答的频道，分流提问解答的需求，而论坛仅仅定位在“交流”、“分享”，不允许出现提问。
产品创新：从依赖明星会员到社区整体竞争力提升 
到了2006年，在Java领域的创新锐减，因此可供讨论的话题少了，再加上严厉的管理制度内容产生不足，社区开始沉寂。
但是，内容不多本身不是个问题。问题反而出现在曾经仰赖的“明星会员”身上。老会员彼此很熟了，开始形成了一股内部政治势力，霸占论坛话语权，排斥新会员。明星会员一呼百应，甚至能制造不利于论坛的舆论，网站和他们的矛盾便不可避免了。
明星会员是双刃剑，一方面能吸引了很多人，是一个网站的核心竞争力之一。但是如果他们过于强势，又会阻碍新人进入，心态膨胀，唯我独尊，成了网站惹不起的主，甚至搞分裂、拉走用户。 
2008年1月网站第二次重写，逐步转型为综合性社区门户。一方面做BBS产品的创新，另一方面开辟了新闻频道、博客、文集、圈子等板块，逐渐减低BBS流量的比重，现在BBS的流量大约只占全站的25%。带来的影响就不是那么大。
综合性内容建设
编辑主导：新闻、专栏
用户自主：论坛、问答
用户完全自主：博客、圈子
成功的关键
1、价值观： 
坚定不移为目标用户群体服务；冷酷无情的抛弃非目标用户 
2、以技术作为核心驱动力 
3、敏捷的产品设计和网站运营 
设计开发上线，最多2~3周就上线了。上线运营后才是关键，产品完善至少2~3个月。博客产品经过了1年的修改。上线后的修改比之前的闭门造车重要的多。 
比如，博客留言是用倒序的。大多数用户的需求建议都是伪需求，他不是站在你的高度去看的。用户为什么要来你这里开博客？博客社区为他的文章做很好的推广、社区氛围很好等等。绝不是为了一大堆功能，因为你做了再多功能也拼不过wordpress。追求功能的用户还是对你不满意。还不如把博客seo做好，把社区做好。勿以善小而不为：深入网站内部，了解每个细节。
目前暴露的问题
1、High performance——对数据库高并发读写的需求 
Web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。
2、Huge Storage——对海量数据的高效率存储和访问的需求 
类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability && High Availability——对数据库的高可扩展性和高可用性的需求 
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如： 
1、数据库事务一致性需求 
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。 
2、数据库的写实时性和读实时性需求 
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。 
3、对复杂的SQL查询，特别是多表关联查询的需求 
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference，各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB
相关新闻
网站被封2010年11月22日消息，国内知名Java编程网站JavaEye被关闭，访问网站被提示：“网站因有违规内容而被关闭，具体事宜请联系您的接入商”。JavaEye创始人、CSDN 产品总监Robbin(范凯)在twitter公开对“关站”一事作出回应是动态防火墙屏蔽了电信监控爬虫所致。
今日14时10分左右，有网友向科技讯反映JavaEye网站被关闭，访问时提示：“网站因有违规内容而被关闭，具体事宜请联系您的接入商”网站域名没有跳转直接显示该内容。
JavaEye创始人、CSDN 产品总监Robbin(范凯)在twitter公开对“关站”一事作出回应，“我写的动态防火墙代码太智能了，把电信负责内容监控的爬虫给封了，结果我就被封了”。Robbin(范凯)透露，网站下午有望恢复访问，并解释了被“封”的原因，是由于代码输入问题，把电信负责内容监控的爬虫给封了，所以导致电信采取“关站”举动。相关新闻补充据IT业人士透露，现在的ID C(接入服务商)或者电信部门，都会要求虚拟主机安装主动式监控软件，同时还会有一些扫描工具“用来做内容监控”，这些软件会自动扫描所有网页和链接，国外称为“机器人”，国内称为“爬虫”。范凯编写的防火墙正是为了针对这种内容监控扫描。范凯还公布了自己的防火墙技术原理，在这篇文章中他称编写此防火墙的原因是因为爬虫“会导致网站访问速度缓慢，甚至无法访问，而且侵犯了网站的版权”。
在微博中，范凯还透露了JavaEye被关的细节，他说他的防火墙封爬虫时会要求填注册码，如果不填注册码才封。“刚才查了一下日志，发现网段被封之后，该网段都有IP登录上来填注册码解封、被封，然后填注册码解封、再被封，几次三番下来，把监管人员逗急了，就下手了。”
22日下午，范凯曾表示“把监控爬虫加入白名单了，争取下午恢复网站访问”，并一度宣布下午6—7点可恢复访问，晚上7点11分又宣布23日上午可恢复访问，但直到23日晚，JavaEye依然无法访问。
JavaEye被逼改名ItEye
JavaEye网站从2011年4月1日起，正式更名为ItEye技术网站，同时网站域名从javaeye重定向到iteye。原因是Oracle公司不准其网站使用JAVA字样，并提出了苛刻条件。JavaEye网站在交涉无效后，不得不做出更名的决定。