豆瓣又崩了！为何此平台动不动就出现崩溃？

服务器崩溃是很常见的事情，尤其是一些用户较多的平台。

近日“豆瓣又崩了”的新闻上了热搜，然而就在豆瓣崩了不到三个小时。下午“小红书崩了”上热搜，可以说这可真是一对难兄难弟。

“小红书”崩是很少见，而豆瓣几乎每隔一段时间就崩了，为何此平台动不动就出现崩溃呢？

原因是：用户实在太多了！服务器忙不过来

豆瓣是一个社区网站。

网站由杨勃创立于2005年3月6日。该网站以书影音起家，提供关于书籍、、音乐等作品的信息，无论描述还是评论都由用户提供，是Web 20网站中具有特色的一个网站。网站还提供书影音推荐、线下同城活动、小组话题交流等多种服务功能，它更像一个集品味系统、表达系统和交流系统(同城、小组、友邻)于一体的创新网络服务，致力于帮助都市人群发现生活中有用的事物。

2012年8月，豆瓣宣布其月度覆盖独立用户数已超过1亿，日均PV为16亿。 2013年第二、三季度的豆瓣月度覆盖独立用户数均达2亿，较去年同期增长一倍。

除了有超大规模的用户外，还有超多数量的app。

豆瓣FM - 号称“月半小乐曲”，大多数80、90后都用过这款app。

豆瓣读书- 豆瓣读书自2005年上线，已成为国内信息最全、用户数量最大且最为活跃的读书网站。

豆瓣- 豆瓣是中国最大与最权威的分享与评论社区，收录了百万条影片和影人的资料。

豆瓣音乐 - 豆瓣音乐是中国最大的音乐分享、评论、音乐人推广社区，拥有最完整的全球音乐信息库、最权威的用户音乐评论，和最具创造力的独立音乐人资源。

豆瓣同城 - 豆瓣同城是国内最大的线下活动信息发布平台，

豆瓣小组- 至今已有30多万个小组被用户创建，月独立用户超过5500万。

可想而知豆瓣服务器有多大的压力，所以出现崩溃也是情有可原。

云主机和服务器的性能一样，有很多的人称之为云服务器或者服务器。
如果是云主机的话，很多的服务器商提供有一键升级，补下差价就可以了。
如果是独立的服务器的话，看你升级什么配置呢？
如果是CPU，的性能不高，内存，硬盘也升级不起来的。
如果是确定可以升级，一般机房增加下内存，硬盘，带宽等
，如果连CPU也要升级，就需要重新做系统了。
海腾晋慧娟，希望你采纳

我想再过1个星期吧。因为这次很久没有更新维护了，而且前几次几乎不到3天就更新完了，应该不会太久。如果你想下载电子书，可以试试迅雷方舟。（不过要注册一个迅雷账号就是了）
----------------
经鉴定，工作人员正在逐步上传资料，按分类来上传
201352 其实现在陆续开始大幅度开放了，这周末希望能升级完

您想问的是轻盐服务器升级要多久是吧，一个月到一年。
据查询CSDN博客网，因业务发展需要，轻盐服务器将进行升级维护，轻盐服务器升级短则一个月，长则一年。
轻盐是一款互动社交平台，可以给予用户更有趣的互动社交体验。

记录分享、发现推荐、会友交流，这是豆瓣在用户网站使用指南中的对用户站内路径的指引，分别也可对应豆瓣导航的三大组成块：品味系统（读书、、音乐）、表达系统（我读、我看、我听）和交流系统（同城、小组、友邻）。

由豆瓣的诞生到这一路的发展，其技术一直被认为是网站成功的关键，有趣的是，豆瓣的技术门槛并不高，所以市场上的模仿者层出不穷，但复制豆瓣不代表就能成功，而在豆瓣之前又为什么没人想到类似的构思呢？

豆瓣全部使用python开发。网站后台的搜索引擎基于Twisted，GUI基于Quixote，还用到了cElementTree，MySQL和PIL，除了这些，豆瓣基本是从头开发（由杨勃一个人四、五个月时间）完成，这是豆瓣技术的基础。纯粹的技术原理之外，相关豆瓣技术还有三个核心原则：符合用户的习惯，简单的前台界面不代表系统的简单。事实上，正相反，在Web20的系统中，后台需要做更多的工作。一些表面看起来很简单的功能背后可能需要大量的程序和计算的支撑。

豆瓣就是最具代表性的例子。与大多数网站不同的是，最早开发的部分是一套推荐引擎，这是基于数学统计的计算模型。在用户点击过看过东西以后，这套模型可以自动分析出“与其口味最像的人”，并主动地推荐用户最有可能喜欢的书籍、音乐或者。

豆瓣是100%动态网站，没有一个静态的页面。我们完全可以将其视为一个个人管理书籍、音乐、影碟的工具，只是将工具放在网上了。很多人抄袭了豆瓣的模式和资源，但就如杨勃所言，仅仅抄袭一个网站的表面是没有价值的。“Google的界面更简单，但系统核心不在这里。豆瓣比Tag这些表面的东西多做了一步，采用了统计模型和一些程序算法，事实上，这才是豆瓣网的核心。”

Web越来越像一个计算平台。通过各种Web应用将计算机连接起来，比如需要相册时可以使用Flickr，需要地图时调用GoogleMap的Api。随着很多服务商逐渐将自己的服务开放出来，每个网站都可以视为一个软件服务提供商，相互之间的联系让系统越来越复杂，而这种系统的复杂并不会带来功能使用的繁琐。

强大的功能、简单的使用，这是WEB20应用的必然趋势。由豆瓣的应用，可以看出发现联系用户之间的关系，在后台建立导引用户功能的连接，针对数据量做好方便的存储和查询，这些就是网站技术的核心。一个令人难以置信的事实是，豆瓣拥有十多万的注册用户，Alexa的流量排名在一千左右，很长的一段时间内却一直就只有一台八千块钱攒起来的服务器、一两个人的开发团队维护着。

为了适应这种规模，开发模式需要进行改变。这在很多Web20的网站中都有体现，有人称之为简单哲学。为了快速开发，系统设计也需要进行简化。杨勃说，“豆瓣网中间也做过一些变动，最初还是受原来做企业系统的影响，结构设计的太复杂，甚至还分了很多层。后来就简化了，因为太复杂之后就难以做快速开发。”

豆瓣采用的是敏捷开发的模式，这是一个快速开发、快速变化的体系，平均每两天就有新的功能出现。

“Web20网站是快速变化的，并不是把所有的功能都在开始阶段完全实现。”杨勃说，“这就要求系统构架的可扩展性要做很好。而且必须考虑将来规模可能带来的问题。豆瓣网一开始的架构设计就可支撑上百万用户。”同时，基于Web的开发省去了客户端分发、维护的成本，因此可以做到“永远的BETA”、随时更新和升级服务。据说，豆瓣学习对象Flickr的升级是以小时为单位的。

Web20与用户的交互也是让网站快速完善的动力。网站运行之后，听取用户的反馈，指导下一步的应用开发。“豆瓣网有一个站务论坛，很多人经常发言提出自己的需求。”比如豆瓣刚开张时，由于每个人都可以自由创建小组或者参加小组，于是用户可能会同时参加几十个小组。但由于很多小组人数比较少，可能很长时间才会有人发言，于是大家就要求有一个功能，把所有小组的最新发言聚合在一起。杨勃很快实现了这个功能，事实也证明非常受欢迎。

杨勃认为，由于是小团队，工作模式就不能是一个经理带一帮人，而是大家都需要参与编程。而且，对综合学习能力的要求比较高。“因为技术变化很快，现在对任何技术再熟悉，经验再多，过几个月可能又出现了新的技术，因此最重要的是要能够跟踪最新的知识。而且由于最新的Web20模式和思想都是从国外发起的，所以程序员要具有在英文环境中直接沟通的能力，能够直接参与到国外开源项目中，而不是看已经翻译为中文的文档。”杨勃表示，自己学习Python也是随豆瓣网开始的。“Python很适合敏捷开发，最初时候曾经尝试过使用Ruby，后来由于豆瓣网需要很多后台的程序，Python更适合编写一些后台模型程序，最终前台也统一为一种语言。”杨勃之前对MySQL了解很少，但在做豆瓣网的过程中，很快将知识弥补上来。“现在我们有几个数据库都可以做同步，有些内容我们还向开源社区进行了回馈。”

豆瓣选用了很多开源产品，杨勃认为：“用好开源产品是非常关键的。豆瓣的平台是基于Linux，数据库用的是MySQL，除了数据挖掘和搜索，其它都是在开源产品之上开发的。因为现在有很多非常成熟的产品和模块，没有必要从头做，只要有能力了解获得这方面的知识，都能够很快在别人的基础上开发自己的系统。”

网络的发展这是非常快的，尤其是时代的不断进步下，网络带着软件一起走进人们的生活里面，比如经典的论坛还有贴吧之类的地方，大家都可以查看信息还有寻找工作等，比较火的就有豆瓣，不过人们会疑惑豆瓣又崩了，豆瓣的服务器怎么了呢我觉得就是服务器性能不够了，实在无法处理如此大的数据访问量，我们来具体分析一下吧。

首先就用周杰伦新发售的歌曲举例，平时我们使用qq音乐之类的音乐软件，压根就不会出现所谓的服务器崩溃之类的，也很是有很大的用户，但是大部分基本上 *** 作都不是同一个数据，就不会有很大的同时访问，所以服务器是完全可以足够支撑的，但是周杰伦发售新歌的时候，直接就会有非常多的用户看同一个信息，这时候直接导致服务器无法处理如此大的数据量，直接就发生了瘫痪崩溃等，这是可以理解的。

同样的道理，以前的豆瓣服务器设计只是一个比较小的范围，但是发展到今天依旧是彻底地改变了，所以就有了很大用户量，这是迸发量直接提高了很多，所以服务器处理不了这么大的数据就导致了经常瘫痪的行为，不过这只是我的角度看法，不见得一定就是这种情况，不过豆瓣的服务器感觉真的可以更换了，实在不行了。

其实最重要的还是像淘宝那样，一开始就看到了很大的数据访问量，所以开始研究了自己的云计算，经过八年的时间成功开创了阿里云服务，如此大的数据都可以轻松搞定，即便是双11这样的超大数据量，服务器依据可以正常运行，这绝对离不开云计算的服务，这是很重要的一点。

但随着信息数据的不断增加，设备持续老化等原因，服务器问题接踵而至，当服务器承载量达到一定限度的时候，管理维护人员则应要考虑对服务器进行升级，以保证服务器对飞速发展是信息化建设的支持。
在考虑升级过程中，用户要根据自己的实际情况出发，不要被服务器销售人员的花言巧语所蒙蔽，首先要对自己服务器配置情况进行详细了解，对企业未来需求进行分析，仔细斟酌，然后制定出最适合服务器的升级方案，以免在升级过程中造成不必要的浪费。这里给大家提供一些升级需要注意的地方，希望对大家在升级过程中能够有所帮助。
一、升级方式1、硬件方面升级：服务器的升级主要围绕着CPU、内存、存储系统和网卡这四个方面。
a、CPU：CPU就是中央处理器，英文为central processing unit。CPU是电脑中的核心配件，只有火柴盒那么大，几十张纸那么厚，但它却是一台计算机的运算核心和控制核心。电脑中所有 *** 作都由CPU负责读取指令，对指令译码并执行指令的核心部件。许多服务器需要升级的地方，CPU运行太慢、导致应用性能受限。
Xeon至强CPU在升级的过程中，要清楚服务器采用的架构、CPU的接口及最大能够支持的CPU数量等问题。目前应用广泛的PC服务器有Intel和AMD架构服务器，以及一些采用台式电脑CPU的低端服务器。这些服务器所采用的CPU架构存在着差异，所以在升级CPU的时候需要先清楚企业服务器采用的是哪一种架构的服务器，然后再了解服务器是否还有升级CPU的空间。但是在确定升级CPU之前，必须明确事务处理速度和并发处理性能两个概念。
另外，如果服务器访问的客户较少，但每位客户都需要服务器提供某种对CPU依赖很大的应用服务，那么，一个高速的单CPU可能是最有用的。但是，如果存在很多个用户同时对大批量的数据提出访问请求，那么在这些访问均以独立的进程程或线程模式打开的情况下，即使是速度较低的多CPU系统也许更为管用。
b、内存：内存条是连接CPU 和其他设备的通道，起到缓冲和数据交换作用。服务器能够支持的最大内存容量一般都有一个限制，如果打算升级服务器的内存，那么需要先了解这台服务器的相关技术参数，以避免升级时达不到要求。
c、存储系统：服务器的存储系统升级主要是两个方面，一个是容量的扩充，另一个是组建RAID阵列以期获得性能的翻倍或数据安全性的翻倍，甚至两者兼有。
如果打算升级，一定要了解服务器主板是否达到相关要求。查看其兼容的品牌型号。
d、网卡：网卡对于服务器来说也是十分重要的一个部件，网卡的吞吐量直接与服务器的整体性能相关，如果服务器的瓶颈出在网卡方面，那么性能再好的CPU，再大的内存，再多的硬盘容量都等于是虚设，所以升级服务器时还是需要注意网卡是否已经成为瓶颈问题。
二、软件方面升级： 除了硬件方面提高产品性能之外，软件方面我们也要进行优化和调试，这样才可以进一步保证服务器性能达到最佳状态。例如：数据库方面，管理软件版本方面（ERP、OA等）相关应用方面都要考虑是不是跟我们升级后的服务器兼容。
三、升级七大注意事项:1、用户应充分评价自己的需求，寻找合适的技术。既不能盲目听从销售人员，也不能只买先进技术的产品，选择贵的，不如选择对的，适合我们的就是最好的。
2、用户要对硬件的兼容性充分了解，使其购买的产品能够很好的兼容。在升级过程中，往往会出现很多浪费情况。例如：虽然买的是最先进的CPU，但是自己的服务器却并不支持，造成了不必要的浪费。
3、注意价格陷阱。要充分理解“一分钱一分货”的道路，在我国，低价销售经常是厂商扔给客户的陷阱，而一些用户又对价格很敏感，所以常常中招。
4、如果用户升级的原因是资源短缺，如CPU太慢、内存太小导致应用性能受限，建议在原有平台架构的基础上扩展资源，如选择更快的CPU，更多的内存，更大的磁盘容量，增加更多的CPU，不要在Unix小型机、PC服务器、新64位系统、高性能服务器之间迁移，甚至不要改变CPU种类和 *** 作系统。
5、如果用户升级的原因是用户的需求由于原来的架构的原因不能满足，如PC服务器的CPU个数、内存大小受限，或4 CPU Unix小型机能带的存储受限，建议在同类系统上升级系统能力，如将2路PC服务器升级到4路或8路，4路Unix系统升级到8路或16路，将SCSI RAID换成FC SAN等。
6、如果用户升级的原因是用户的需求由于应用的架构的原因不能满足，可以考虑改变系统架构；如所有应用运行在一个SMP系统上性能受限，可以采用机群系统分散应用，提高可扩展性；又如数据库在PC服务器上受I/O带宽的影响，无法保证事务处理能力，可以升级到大型SMP Unix系统。
7 、如果用户升级的原因是出于节省成本的考虑，可以参照下面的近似公式；目前服务器的价格比例近似于，高档PC: Xeon服务器：UNIX服务器 = 1: 2: 4; 另外，机群系统：大型SMP系统 = 1: 2，用户可以根据资金情况选择平台。
刚才在上面已经谈到了，硬件升级是其一，软件优化服务器同样也能让老机器发挥余热（比如采用虚拟化技术就可以让我们的服务器提高使用率）。同时还要注意现在硬件更新速度远远高于软件更新速度，在选购服务器产品时我们要软硬兼施，两手抓都要硬。尽量站在2年后地位置思考问题，做出预估，这样才可以保证服务器持续不断地满足应用需求。

---