一、入驻成为开发者要使用开放平台任何设施首先要成为开放平台开发者。打开开放平台首页，使用淘宝账号登陆，点击右上角的入驻开放平台，提交开发者信息，完成开发者入驻。二、创建应用1.选择正确的应用标签开放平台目前将所有开放的业务分为移动应用、电商管理、广告推广以及其他4类。（1）移动应用基于不同移动平台而产生的开放业务，包括手机（平板）、YunOS、TvOS和车联平台等;（2）电商管理基于淘宝/天猫的商业平台，提供商家或者第三方开发者开发IT软件管理电商业务的接入方式，可根据面向的对象和实现的业务需求不同而选择不同的应用标签，如面向商家、面向工具服务商、面向码商等（3）广告推广基于阿里妈妈广告或淘宝客体系开放的接入方式（4）其他通信、安全等创新型业务及技术能力的开放2.申请应用标签权限选择申请权限，根据流程指导提交开发者信息图示为互动应用申请的信息要求，不同应用标签对信息提交的要求会不一致。一般应用标签均需要5-7个工作日的审核周期，少部分业务由于需求旺盛会不需要审核，请根据流程提示进行操作。需要了解应用标签审核状态可以在控制台-创建应用页面查看已获得和申请中的应用标签3.创建应用已经获取应用标签权限后，可以直接在控制台-创建应用页面中选择申请到权限应用标签创建应用填写应用名称，完成应用创建。4.获取AppKey和AppSecret进入应用管理，在概览页面的APP证书可以查看AppKey和AppSecret。在应用开发调试前需要先补充应用基本信息,包括应用图标（部分应用标签下可选）、商家授权回调地址（部分应用标签下可选）;回调地址的主要作用是在使用开放平台oAuth2.0获取获取SessionKey(或AccessToken)时，服务器会将登陆授权成功后的信息返回给回调地址三、SDK的下载和环境依赖淘宝开放平台SDK提供了API的请求封装、摘要签名、响应解释、消息监听等功能，使用SDK可以轻松完成API的调用，API结果的获取，消息的实时监听。1.环境依赖JAVASDK需要依赖JavaSE/EE1.5及以上（不支持Android平台）.NETSDK需要依赖.NETFramework2.0及以上（不支持WindowsPhone平台）PHPSDK需要依赖PHP5及以上PythonSDK需要依赖Python2.7以及上2.如何下载由于应用要先拥有API的访问权限，才能调用此API，所以SDK的下载是与应用相关联的，不同的应用下载到的SDK是各不一样的。第一步：注册成为淘宝开放平台开发者，并创建一个应用（如果此步已完成，可跳过）第二步：登录淘宝开放平台，进入控制台，进入其中一个应用的SDK下载页面第三步：选择需要的语言进行下载，如果需要下载最新的SDK，请点击重新生成
404页面是网站优化中必不可少的基础优化之一，随着网站运营时间的不断延长，网站上原来的网页内容可能会被删除，但是该网页的链接地址往往会以各种内链、外链形式存在，如果使用的是一些锚文本链接，这些文字内容可能会吸引到用户点击，而对应的页面却已经删除，此时如果没有设置404页面，那么用户获得的页面就是一个错误的页面，而搜索引擎获得的路径则变成了死路。正因如此又将这类链接称之为死链一、什么是404页面404页面是客户端在浏览网页时，服务器无法正常提供信息，或是服务器无法回应，且不知道原因所返回的页面。当用户输入了错误的链接时，返回的页面，它会告诉浏览者其所请求的页面不存在或链接错误，同时引导用户使用网站其他页面而不是关闭窗口离开，自定义404错误页面是增强用户体验的很好的做法。二、404页面作用404页面是网站必备的一个页面，它承载着用户体验与SEO优化的重任。404页面通常为用户访问了网站上不存在或已删除的页面，服务器返回的404错误。如果站长没有设置404页面，会出现死链接，蜘蛛爬行这类网址时，不利于搜索引擎收录。三、404页面错误提示是WWW网站访问比较经常出现的错误。最常见的出错提示：404NOTFOUND。404页面就是当用户输入了错误的链接时，返回的页面。四、404页面对seo的影响自定义404错误页面是增强用户体验的很好的做法，但在应用过程中往往并未注意到404页面对搜索引擎的影响，譬如：错误的服务器端配置导致返回状态码“200”或自定义404错误页面使用MetaRefresh导致返回“302”状态码。五、404页面设置的好处1、引导用户不要关闭网站，增强用户体验。2、防止网站出现死链接。六、404页面设置方法方法一：下载404页面模板1、下载后，解压文件，里面有一个404文件夹和404.php两个文件；如下图；需要注意的是404文件里面有一张图片，图片和404文件夹请不要重命名，以免影响显示效果。2、用Dreamweaver软件，打开404.php这个文件，如下图所示，将双引号之间的“http://xxjz001.com”修改成你自己的网址，修改完成后，点击“文件”-“保存”。3、打开FTP上传工具，将404文件夹和404.php上传到网站的根目录的主题文件夹，如果提示覆盖的话直接覆盖。（若你不知道你的网站根目录是哪个文件夹，可以咨询你的空间服务商）。4、上传完成后，登陆空间控制面板，找到出错页面（一般空间的名称可能有所不同，要是没找到的话就咨询一下空间服务商看看），在“出错页面”中进行设置。5、最后我们打开浏览器，输入我们的网址，在网址后面随意敲打一些字母或数字，然后回车，就能看到如下404页面效果图了，当我们点击“返回网站首页”时，就会回到我们网站的首页，这样一个简单的404页面就设置好了！方法二：制作404页面1、打开Dreamweaver软件，（不知道Dreamweaver软件怎么用的话百度，这里就不多说了）点击新建php文件，在标题中自定义书写你想要书写的内容，在标签中自定义书写你想要书写的内容，然后点击文件保存，文件名为404，保存到桌面。2、打开FTP软件，登陆FTP，找到网站根目录，找到主题文件件，找到404.php文件，把制作好的404页面上传，替换原来的404.php，如果提示覆盖直接覆盖。打开网站，输入错误地址，检测404页面是否生效。这样我们网站404页面最简单的制作就完成了。方法三：（适合对wordpress代码比较熟悉的同学来操作，若你对代码尚不熟悉的情况下，这里建议你使用第一种方法来设置404页面）1、我们通过学习“wordpress模板结构分析”，我们知道index.php是存放网站的首页模板的地方，当然了，事实上这也不完全是这样的，首页模板的名称与制作主题（模板）的人的习惯和喜好有关，这只是一个代号而已，如果你高兴，这个代号叫“awt”、“bog”都行，熟悉代码的童鞋一般就能很快找到首页模板的文件。2、找到首页模板文件后，（这里我们拿index.php文件来演示），从FTP工具上下载下来，并重命名为404.php3、用Dreamweaver软件打开404.php，将文件中最大的标签里面的内容全部删除，然后在标签里面书写如下内容：你要查找的内容不存在！返回网站首页编辑好后，点击“文件”-“保存”。4、将修改好的404页面上传至你的网站根目录/wp-content/themes/你安装的主题/这个路径即可。以上三种方法就是比较简单的404页面设置，当然现在大部分网站主题都自带了404页面设置，如果你不满意网站主题自带的404页面的话可自行制作或修改。七、设置404页面注意事项1、不要将404错误直接转向到网站首页，这将导致首页不被收录2、/Error.html前面不要带主域名，否则返回的状态码是302或200状态码3、404页面符合网站自身的设计风格，最好能加入网站导航和底部（尤其是网站地图）4、不要使用绝对URL，如果使用绝对URL返回的状态码是302+2005、404页面设置完成，一定要检查是否正确。但http头信息返回的一定要是404状态。这主要是对搜索引擎有关系，因为如果你网站产生较多页面时候但搜索引擎看到的是很多一样的正常页面，有可能会误被认为作弊。6、404页面不要自动跳转，让用户来决定去向。这涉及到404页面的制作，提供用户体验很重要，404页面制作很有学问。7、提示访客检查拼写还有一个可能：访客看到404错误页面是由于他们自己在输入URL网址时出现了拼写错误。提示访客检查他们的拼写，但不要失礼。就像我们在上面提到的，你的措辞不要让访客们感到你是在责备他们。8、让页面返回404每个网页都有一个服务器响应代码。代码200是指页面一切正常，404则是指页面无法被找到。如果你已经指定了自定义的404错误页面，则需要确保页面的标题是返回正确的响应代码。有几种不同的方法可以做到这一点，最简单的就是用你的htaccess文件来指定错误页面。9、帮助访客404错误页面已经呈现在访客面前，表明这个页面并不是他们正在搜寻的。所以你应该设法帮助他们找到原来的页面。确保你的错误页中包含一个选项来协助用户寻找他们想要的页面，甚至可以包括有过更改的页面的链接。10、放置网站主页链接不要让访客无处可去或是无法找到你的网站信息。至少应该有一个链接链回你的网站主页。这样一来，从其他网站链接而来的访客就可以了解你以及你的网站，甚至他们可能在你的网站中找到一些他们喜欢的内容。11、保持品牌风格我们都看过非常酷的“让访客发现一个巨大的“复活节蛋”“的错误页面的设计案例。但千万不要使这个页面的设计与你网站的其他页面相差太大，否则会看起来这个页面不像你网站的设计，会让访客产生疑惑，误以为自己已经被带到了一个外部网站。12、修复你的无效链接如果你得到的数据显示有大量的访客访问您的404页面（检查你的网站的分析数据来确定数量），这表明你的网站上有很多无效链接。你完全可以通过修复这些链接来阻止访客进入404页面。像SiteBeam和Nibbler这样的网站测试工具可以帮助检查是否有无效链接，使你能够迅速找到并修复他们而不必等待别人来告诉你。总结：尽管404页面被用户看到的概率相对全站的其他页面要小很多，但随着网站的长期积累，404页面难免会出错（如星辰seo博客，虽然现在页面不是很多，但最近也曾出现过错误的链接。）无论是用户的误操作还是服务器的原因，这是一个极少数才会出现的错误情况，作为网页的设计者或者开发者，有时候我们无法控制错误页面的出现，但我们可以通过使用一个定制的404错误页面将损害降到最低。好的用户体验是我们不能放过任何一个小的细节，一我们需要在这个页面很好的把信息传达给用户，二引导用户下一步的操作，引导用户留在我们的网站而不是沮丧的关闭窗口。从而提高用户体验，最后我要说的就是虽然404页面属于网站结构优化中的一个细节部分，只要我们把这些细节问题一一了解透彻，我相信对于一般的网站的SEO诊断是没任何问题的,希望本篇文章能帮到SEO新手。以上就是对浅析网站404页面设置方法和注意事项全部内容的介绍，更多内容请继续关注站三界导航！
什么是移动适配，移动适配工具的作用提升搜索用户在百度移动搜索的检索体验，会给对应PC页面的手机页面在搜索结果处有更多的展现机会，需要站点向百度提交主体内容相同的PC页面与移动页面的对应关系，即为移动适配。为此，百度移动搜索提供“移动适配”服务，如果您同时拥有PC站和手机站，且二者能够在内容上对应，即主体内容完全相同，您可以通过移动适配工具进行对应关系提交。站长通过移动适配工具提交pattern级别或者url级别的PC页与手机页对应关系，若可以成功通过校验，将有助于百度移动搜索将移动用户直接送入对应的手机页结果。积极参与“移动适配”，将有助于您的手机站在百度移动搜索获得更多流量，同时以更佳的浏览效果赢取用户口碑。移动适配工具如何使用当您同时拥有移动站点和PC站点、且移动页面和PC页面的主体内容完全相同，就可以在通过百度站长平台提交正确的适配关系，获取更多移动流量。第一步，注册并登录百度站长平台第二步，提交PC网站并验证站点与ID的归属关系第三步，站点验证后，进入“工具”――“移动专区”――“移动适配工具”，选择具体需要进行移动适配的PC站，然后“添加适配关系”第四步，根据自己提交的适配数据特点，选择适合您的提交方式：目前移动适配工具支持规则适配提交URL适配提交，无论您使用哪种方式都需要先指定PC与移动站点，此举可以令平台更加快速地检验您提交的数据、给出反馈，顺利生效。同时您在之后步骤中提交的适配数据中必须包含指定的站点，否则会导致校验失败。1）规则适配：当pc地址和移动地址存在规则（pattern）的匹配关系时（如PC页面www.a.com/picture/12345.html，移动页面m.a.com/picture/12345.html），可以使用规则适配，添加pc和移动的正则表达式。强烈建议您使用规则适配，一次提交成功生效后，对于新增同规则的URL可持续生效，不必再进行多次提交。同时该方式处理周期相对URL适配更短，且易于维护和问题排查，是百度推荐使用的提交方式。2）URL适配：当规则适配不能满足适配关系的表达时，您可以通过“URL对文件上传”功能，将主体内容相同的pc链接和移动链接提交给百度：文件格式为每行前后两个url，分别是pc链接和移动链接，中间用空格分隔，一个文件最多可以提交5万对url，您可以提交多个文件。另外您还可以选择“URL对批量提交”，在输入框中直接输入url对，格式与文件相同，但此处一次性仅限提交2000对url。第五步，提交适配数据后，关注移动适配工具会提供状态说明，若未适配成功，可根据说明文字和示例进行相应的调整后更新提交适配数据。移动适配目录如何使用工具提交适配关系PC站点下开辟某个目录存放移动适配页面、作为移动适配“站”时，依然会有提交移动适配数据的需求，如：https://www.a.com/a.html适配到https://www.a.com/m/a.html。虽然从长远角度看，这种行为对搜索引擎极不友好，百度（包括GOOGLE）一直不赞成不鼓励这种建方式。但为了满足该需求，百度站长平台移动适配工具依然提供满足此需求的功能。您可以先在下拉菜单中选择准确的站点域名，再点击“+添加适配关系”。也可以在默认的www主域下“+添加适配关系”。进入“添加新数据”界面后，“指定PC-移动站点”处填写的移动站点名，要与PC站点名一致，然后在提交规则处填写相应的正则信息，然后增加校验用url对即可。提交数据时示例图如下：移动适配状态说明校验中：百度站长平台会对管理员提交的移动适配数据进行校验，当认为实际情况与您提交的情况相符时，才会对适配数据进行生效处理，这个校验时间大约为10天。目前“校验中”的适配数据不能删除。校验失败：当百度站长平台发现站点存在如下问题时，会判为校验失败，不会进行后续的生效处理： a、正则格式错误：请按照规定的格式进行填写，详见《正则格式说明》。 b、PC-移动页面不对应:PC链接和移动链接的主体内容不相同，达不到对应关系 c、数据内容和适配类型不符：提交的适配关系内容有错误，管理员错误地通过规则适配功能提交了url对，或者相反的情况 d、数据内容与指定站点不一致：提交的适配关系与提交的指定站点不对应 e、未达到校验标准。提交面的“？”号获取的适配数据中，PC页面或移动页面没有收录。移动适配工具对适配数据进行正确性校验时依赖PC网页库和移动网页库中已收录的页面，如果校验时取到的PC页或移动页百度还未收录，将无法对适配数据进行检验。对于未收录的页面将推送给spider进行抓取，若收录后可进行下一次正确性检验,管理员不必再另行提交。*页面被收录不等于被建索引，收录了的页面有可能在索引量工具里查不到。以上错误信息会抽样展示在错误详情页面中，您可以通过点击状态说明获取校验成功：您提交的适配数据通过校验后，百度站长平台会进行生效处理，这个过程最长为10天。校验部分成功：您提交的适配数据中包含部分校验失败内容，失败部分可以参考校验失败的说明，其他成功部分会上线生效。未达到校验标准：您提交的规则所涉及的页面，绝大多数未收录（区别于索引）或展现过少，平台工具为了高效处理海量规则，会将未达到校验标准的规则做延后处理，站点方面不必再做额外工作。适配成功：百度已经根据您提交的适配数据对移动链接进行了替换。适配部分成功：对应校验部分成功而言，那部分通过校验的数据已完成移动适配。内容重复：此文件提交的数据被后提交的文件包含覆盖，工具后续不会再对该文件进行处理，也不会反馈处理状态移动关系发生变化如何修改站长通过移动适配工具提供适配数据中若发现数据有误，或想更新旧的、已生效的适配关系，可以重新提交新的适配数据予以覆盖。具体如下：1、目前“校验中”的数据不支持直接删除，若此时需要修改适配关系数据，不需要等等该数据更新状态，可以直接提交新的适配关系予以覆盖。2、如适配数据发生校验失败，无需将其删除，直接提交新的适配关系覆盖即可。3、若需要修改已适配成功的关系数据，无需将原适配数据删除，直接提交新的适配关系覆盖即可，待新数据适配成功后线上可生效。 移动适配工具注意事项1、只要PC站点与移动站点的主干一致，即可参与移动适配。举例说明：PC站点ww.jb51.com.cn 移动站点m.a.com 属于主干一致。当然我们更建议您使用主域相同的PC站点和移动站点2、建议您尽量使用规则适配进行对应关系提交，一次提交可对于新增同规则的URL持续生效，无需多次反复提交，且处理周期相对URL提交更短，更易于维护和问题排查，是百度推荐使用的提交方式3、使用正则格式进行规则适配，尽量使用最小的粒度来表示，这样更容易校验通过，比如： a）.确定是纯数字：([0-9]+)或（\d+） b）.确定是纯字母：([a-zA-Z]+)，包括字母大小写的情况 c）.确定是数字和字母混合串： 方法一、((?:[a-zA-Z]+[0-9]+|[0-9]+[a-zA-Z]+)[a-zA-Z0-9]+) 方法二、([a-zA-Z0-9]+) 说明：两种混合串的区别：较长的一种为严格的数字和字母混排形式，且数字和字母交替至少出现1次； 较短的一种可支持纯数字，纯字母和数字字母混排 d）.确定有中文字符：((?:%[a-zA-Z-0-9]{2,})+) e）.确定有参数值：([^&]+) f）.确定有'-'和'_'连接字符串的替换规则：将连接的各个部分分别用对应的规则替换4、百度站长平台对适配数据的校验时间大约为10天，生效时间大约为1-2天。5、适配成功后要继续保持正确的适配关系，我们会重复验证适配关系的有效性。 如何提升移动适配效果首先，对已有的对应关系持续进行适配，同时不断建设新的对应关系，增加适配覆盖的范围。其次，要确保已经提交的对应关系准确。以下是常见的对应不准确错误，请网站进行自查，并及时修改。1、手机页不可用，比如死链。2、robots封禁。放开对Baiduspider的robots封禁，以便Baiduspider获取您PC站与手机站之间的对应关系。3、手机页使用了ajax等异步加载的方法加载内容主体。4、格式错误。正则格式错误，文件格式错误等。5、对应关系错误1）当PC页为内容页时，应该适配到对应的手机页内容页，而实际却适配到手机页的首页/列表页例如PC页为https://www.a.com/Book/2083259.aspx，适配后的手机页为http://m.a.com/?from=web2）手机页本身无主体内容或主体内容过少。3）手机页需登录才能浏览主体内容。4）PC页内容与手机页内容不存在一一对应关系。 正确的对应关系示例： PC页https://www.a.com/mmmshandongrencai/ 手机页http://m.a.com/w/mmmshandongrencai/ 正则格式说明以站点news.a.com适配到站点m.a.com为例:适配PC链接地址为：http://news.a.com/09/1001/07/5KH8DE1F000120GR.html，适配移动链接地址为：http://m.a.com/news/09/1001/07/5KH8DE1F000120GR.html步骤一：确定适配链接中的可替换参数或者路径，得到其位置序号和类型。适配PC链接：根据网站自身url的层次结构，其中09,1001,07和5KH8DE1F000120GR为动态可替换的路径。除5KH8DE1F000120GR为字母和数字混合外，其余均为纯数字。步骤二：根据可替换参数或路径的类型，得到链接的表达形式。使用正则匹配符号(\d+)或者(\w+)表示该路径或参数。(\d+)表示纯数字字符串，(\w+)表示字母数字下划线组成的字符串。步骤三：根据移动链接，以及可替换参数在步骤一中的位置序号，依次用${1}，${2}，……表示替换掉适配PC链接中的可替换参数或路径，得到适配后的移动链接的pattern形式。至此，便得到了适配的规则：http://news.a.com/(\d+)/(\d+)/(\d+)/(\w+).htmlhttp://m.a.com/news/${1}/${2}/${3}/${4}.html 正则格式示例：1、纯数字替换生成pattern例子：eg1:url对应关系：https://www.a.com/26299483.html-> http://m.a.com/26299483.html pattern： https://www.a.com/([0-9]+).html-> http://m.a.com/${1}.htmleg2:url对应关系：https://www.a.com/t26299483.html-> http://m.a.com/26299483.html pattern： https://www.a.com/t([0-9]+).html-> http://m.a.com/${1}.html 2、纯字母替换生成pattern例子：eg:url对应关系：https://www.a.com/fawliute/->http://m.a.com/fawliute/ pattern： https://www.a.com/([a-zA-Z]+)/-> http://m.a.com/${1}/ 3、字母和数字混合的字符串替换生成pattern的例子：eg1:url对应关系：https://www.a.com/a1cc1n2q5y3/-> http://m.a.com/a1cc1n2q5y3/ pattern： https://www.a.com/((?:[a-zA-Z]+[0-9]+|[0-9]+[a-zA-Z]+)[a-zA-Z0-9]+)/ ->http://m.a.com/${1}/ 注意：字母和数字混合字符串，字母和数字必须交替出现至少1次有效例子：a13b，23a9，da3bc99，42a1ceg2:url对应关系：http://news.a.com/09/1001/07/5KH8DE1F000120GR.html ->http://m.a.com/news/09/1001/07/5KH8DE1F000120GR.html pattern: http://news.a.com/([0-9]+)/([0-9]+)/([0-9]+)/([a-zA-Z0-9]+).html ->http://m.a.com/news/${1}/${2}/${3}/${4}.html 4、对于字母和数字只交替出现一次的，可以分别用数字和字母进行正则替换：eg:url对应关系：https://www.a.com/az123/ -> http://m.a.com/az123/ pattern： https://www.a.com/([a-zA-Z]+)([0-9]+)/->http://m.a.com/${1}${2}/ 5、中文字符串正则替换生成pattern例子：eg:url对应关系：https://www.a.com/长城花园/->http://m.a.com/长城花园/ pattern： https://www.a.com/((?:%[a-zA-Z0-9]{2,})+)/->http://m.a.com/${1}/ 6、由'-'或者'_'连接的数字或者字母替换生成pattern的例子：eg:url对应关系：https://www.a.com/byd-c3/->http://m.a.com/byd-c3/ pattern： https://www.a.com/([a-zA-Z]+)-([a-zA-Z]+)([0-9]+)/->http://m.a.com/${1}-${2}${3}/注意：'-'和'_'出现多次可以使用同样的方式处理 如：abc-134_x-1 7、对参数部分进行正则替换生成pattern的例子：eg:url对应关系：https://www.a.com/article.html?act=test&id=123 -> http://m.a.com/article.html?act=test&id=123 pattern： https://www.a.com/article\.html?act=([^&]+)&id=([^&]+) ->http://m.a.com/article.html?act=${1}&id=${2} 8、PC存在分页对应移动页面生成pattern的例子：eg:url对应关系：https://www.a.com/1234-1.htm https://www.a.com/1234-2.htm ->http://m.a.com/1234.htm pattern： https://www.a.com/([0-9]+)-([0-9]+).htm-> http://m.a.com/${1}.htm
百度移动适配工具使用前提首先：你必须得有PC站和手机站，也就是说必须有两套URL系统。自适应的网站因为是同一套URL，所以不在适配行列。如果你没有技术支持，恰巧运营的是问答站，那么推荐Wecenter。该产品包含了移动端。其次：PC站与手机站的主体内容必须一致，否则无法通过校验。言下之意，告诫站长不要作弊。因为确实有人投机取巧，试图蒙混过关。当然也有很多确实是因为移动端和PC端展示的版块不一致而导致校验失败。此时需要产品调整移动端。百度移动适配好处1、提高手机站在百度移动端的流量。正则匹配同样适用于阿里的神马搜索、搜狗的移动搜索。2、因为手机站的浏览效果更佳，用户体验更棒，所以可能赢得用户口碑，并大大促进品牌的知名度。百度移动适配两种规则：规则适配与URL适配一、pattern适配当PC网址和移动网址存在规则（pattern）匹配关系时，可以使用此规则，添加PC和移动的正则表达式。百度强烈建议使用这种规则适配。因为此规则有两个优势：pattern适配两个优势1、一次提交成功生效后，对于新增同规则的URL可持续生效，不必重复提交。2、百度生效周期更短，且易于维护和问题排查。正则匹配格式说明注：使用正则格式进行规则适配，尽量使用最小的粒度来表示，这样更容易校验通过。a)确定都是数字的，则用(\d+)表示b)确定都是字母的，则用([a-zA-Z]+)表示c)确定是字母数字混合，则用([a-zA-Z0-9]+)表示d)确定是字母数字下划线混合，则用(\w+)表示只有在规则粒度无法用上述a和b形式表示时，才用c形式表示；只有在规则粒度无法用a、b、c表示时，则才用d形式表示。若a、b、c、d形式都无法满足，则认为是复杂对应关系，需要使用下方的URL适配。二、URL适配当规则适配不能满足适配关系的表达时，可以通过“URL对文件上传”功能，将主体内容相同的PC链接和移动链接提交给百度。有以下两种方法：1、选择“上传URL对文件”。文件格式为每行前后两个url，分别是pc链接和移动链接，中间用空格分隔，一个文件最多可以提交5万对url，可以提交多个文件。2、选择“填写URL对”，在输入框中直接输入url对，格式与文件相同，但此处一次性仅限提交2000对url。规则适配注意事项1、百度站长平台对适配数据的校验时间大约为10天，生效时间大约为1-2天。2、适配成功后要继续保持正确的适配关系，百度会重复验证适配关系的有效性。
我们先以聊天室为例来讲， web聊天室的实现方法有多种，包括：基于ajax技术的实现，基于Comet（Pushlet）技术的实现，基于XMPP协议的实现，以及基于flash的XmlSocket和远程共享对象的实现。 （1）基于ajax技术的实现。 ajax（异步JavaScript和XML，Asynchronousjavascriptandxml），它的作用就是可以实现页面与服务器端的无刷新交互。用ajax来实现web聊天室的基本原理是：在页面上每隔一段时间就通过ajax从服务器中获取数据，然后更新页面显示。这种方法简单明了，缺点是实时性不高。 （2）基于Comet技术的实现。 Comet是一种新的Web应用架构。基于这种架构开发的应用中，服务器端会主动以异步的方式向客户端程序推送数据，而不需要客户端显式的发出请求。Comet架构非常适合事件驱动的Web应用，以及对交互性和实时性要求较高的应用，如股票交易行情分析、聊天室和Web版在线游戏等。 Pushlet是一种comet实现（Pushlet是开源的Comet框架）：在Servlet机制下，数据从服务器的Java对象直接推送（push）到客户端的页面，而无需任何Javaapplet或者插件的帮助。它使server端可以周期性地更新client的web页面，这与传统的request/response方式不同。 Pushlet基于HTTP流，这种技术常常用在多媒体视频、通讯应用中，比如QuickTime。与装载HTTP页面之后马上关闭HTTP连接的做法相反，Pushlet采用HTTP流方式将新数据源源不断地推送到client，再此期间HTTP连接一直保持打开。有关如何在Java中实现这种Keep-alive的长连接请参看Sun提供的《HTTPPersistentConnection》和W3C的《HTTP1.1规范》。 （3）基于XMPP协议的实现 XMPP（可扩展消息处理现场协议）是基于XML的协议，是专为及时通信系统设计的通信协议，用于即时消息以及在线现场探测。它在促进服务器之间的准即时操作。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。XMPP的前身是Jabber，一个开源形式组织产生的网络即时通信协议。著名的开源聊天系统服务器Openfire就是基于XMPP协议的Jabber服务器。 可以通过Flash或ajax与Jabber服务器进行交互，实现webIM的功能， （4）基于flash的XmlSocket的实现 FlashMediaServer是一个很强大的流媒体服务器，它基于rtmp协议，提供了强壮的流媒体交互功能。在FMS中，提供一种远程共享对象（SharedObject）的机制，客户端可以创建并连接到服务器端的远程共享对象。可以有很多个客户端连接到同一个远程共享对象中，任何一个客户端对共享对象进行了修改，服务器都会将共享对象的修改信息发送给所有其他连接到这个共享对象的客户端。这种远程共享对象的机制可以很方面地实现以下功能：· 远程控制幻灯片放映 · 文字聊天 · 网络对战 · 远程选择和播放歌曲 · 现场拍卖 · 客户服务应用程序。 远程共享对象很适合用于实现web聊天室中的群聊功能。为每一个群都建立一个远程共享对象，这样的话，任何用户在群上发信息，就可以通过服务器自动发送到所有的群成员。 用远程共享对象来实现单聊是不实际的。对应单聊的实现，我们需要借助socket。客户端通过socket服务器与其他客户端进行私聊。聊天信息通过socket服务器进行转发。 这种方式是效率最高的web聊天室实现方式。即时通讯系统架构简单地介绍一下大型商业应用的IM系统的架构。设计这种架构比较重要的一点是低耦合，把整个系统设计成多个相互分离的子系统。我把整个系统分成下面几个部分：（1）状态消息系统 （2）好友系统 （3）P2P系统 （4）其他扩展业务系统先看状态消息系统（1）connd client接入服务器，可以支持UDP，也可以支持TCP，一般建议优先选择TCP。connd可以布置多台，client接入时，可以用简单的DNS轮询的方式实现负载均衡。connd功能是维护连接和转发消息包。（2）pconndproxyconnd,代理接入服务器，是connd的扩展，除了有connd的功能外，支持服务器的接入，比如webserver。（3）msgd消息处理服务器，主要功能是用户状态管理，消息转发(包括合理性验证)以及离线消息保存。说一个用户登录成功后，对所有好友的状态通知过程。我设计的系统中，把用户状态也简单看成类似文本聊天消息。下面用户U的上线过程，他有好友F1,F2。（1）connd收到U上线消息，将消息发给U所在的msgd。（2）msgd获取U的好友，F1,F2；如果F1,F2和U不在同一个msgd上，msgd将消息通过connd转给F1,F2所在的msgd。（3）最终的msgd把上线通知通过connd发给F1,F2。msgd的U是通过什么方式获取最新的好友呢？这个问题我要着重描述一下。用户的好友数据都在另外一个子系统中：好友子系统。msgd通过TCP的方式（为什么用TCP呢？）主动从好友系统获取。同时，msgd也缓存一份好友数据。msgd获取用户好友时，如果cache是最新的，直接从cache取，否则要从好友子系统那边取。现在重点问题出来了，如何确定用户的好友是最新的？这类问题我们要根据不同的业务不同的特点灵活采用不同的方法。请看一种高效的处理方式：（1）好友子系统为每个用户的好友算个hash值（可以用MD5）。（2）client获取好友时，同时也拿到这个hash值；发和好友相关的消息时，把hash值带给msgd。（3）msgd第一次从好友子系统获取某个用户好友时，也获取这个hash值；像要转发状态消息，获取好友时，把client带过来的hash1和自身的hash2比较一下。。。像IM这种业务特点是，对好友数据的写很少，读很多，相对于读的消耗，写基本可以忽略的。用上面的方法，基本上每次两者的hash值是相等的，直接从cache拿好友数据。这种处理方法也可以引入到其他应用业务中。建议不要每次都粗暴地跨进程获取类似好友数据。
现在几乎任何一个网站、WebApp以及移动APP等应用都需要有图片展示的功能，对于图片功能从下至上都是很重要的。必须要具有前瞻性的规划好图片服务器，图片的上传和下载速度至关重要，当然这并不是说一上来就搞很NB的架构，至少具备一定扩展性和稳定性。虽然各种架构设计都有，在这里我只是谈谈我的一些个人想法。 对于图片服务器来说IO无疑是消耗资源最为严重的，对于web应用来说需要将图片服务器做一定的分离，否则很可能因为图片服务器的IO负载导致应用崩溃。因此尤其对于大型网站和应用来说，非常有必要将图片服务器和应用服务器分离，构建独立的图片服务器集群，构建独立的图片服务器其主要优势：1）分担Web服务器的I/O负载-将耗费资源的图片服务分离出来，提高服务器的性能和稳定性。2）能够专门对图片服务器进行优化-为图片服务设置有针对性的缓存方案，减少带宽网络成本，提高访问速度。3）提高网站的可扩展性-通过增加图片服务器，提高图片服务吞吐能力。 从传统互联网的web1.0，历经web2.0时代以及发展到现在的web3.0，随着图片存储规模的增加，图片服务器的架构也在逐渐发生变化，以下主要论述三个阶段的图片服务器架构演进。 初始阶段在介绍初始阶段的早期的小型图片服务器架构之前，首先让我们了解一下NFS技术，NFS是NetworkFileSystem的缩写，即网络文件系统。NFS是由Sun开发并发展起来的一项用于在不同机器，不同操作系统之间通过网络互相分享各自的文件。NFSserver也可以看作是一个FILESERVER,用于在UNIX类系统之间共享文件，可以轻松的挂载(mount)到一个目录上，操作起来就像本地文件一样的方便。 如果不想在每台图片服务器同步所有图片，那么NFS是最简单的文件共享方式。NFS是个分布式的客户机/服务器文件系统，NFS的实质在于用户间计算机的共享，用户可以联结到共享计算机并象访问本地硬盘一样访问共享计算机上的文件。具体实现思路是： 1)所有前端web服务器都通过nfs挂载3台图片服务器export出来的目录，以接收web服务器写入的图片。然后[图片1]服务器挂载另外两台图片服务器的export目录到本地给apache对外提供访问。2）用户上传图片用户通过Internet访问页面提交上传请求post到web服务器，web服务器处理完图片后由web服务器拷贝到对应的mount本地目录。3）用户访问图片用户访问图片时，通过[图片1]这台图片服务器来读取相应mount目录里边的图片。 以上架构存在的问题：1）性能：现有结构过度依赖nfs,当图片服务器的nfs服务器有问题时，可能影响到前端web服务器。NFS的问题主要是锁的问题.很容易造成死锁,只有硬件重启才能解决。尤其当图片达到一定的量级后，nfs会有严重的性能问题。2）高可用：对外提供下载的图片服务器只有一台，容易出现单点故障。3）扩展性：图片服务器之间的依赖过多，而且横向扩展余地不够。4）存储：web服务器上传热点不可控，造成现有图片服务器空间占用不均衡。5）安全性：nfs方式对于拥有web服务器的密码的人来说，可以随意修改nfs里边的内容，安全级别不高。 当然图片服务器的图片同步可以不采用NFS,也可以采用ftp或rsync，采用ftp这样的话每个图片服务器就都保存一份图片的副本，也起到了备份的作用。但是缺点是将图片ftp到服务器比较耗时，如果使用异步方式去同步图片的话又会有延时，不过一般的小图片文件也还好了。使用rsync同步，当数据文件达到一定的量级后，每次rsync扫描会耗时很久也会带来一定的延时性。 发展阶段当网站达到一定的规模后，对图片服务器的性能和稳定性有一定的要求后，上述NFS图片服务架构面临着挑战，严重的依赖NFS,而且系统存在单点机器容易出现故障，需要对整体架构进行升级。于是出现了上图图片服务器架构，出现了分布式的图片存储。 其实现的具体思路如下：1）用户上传图片到web服务器后，web服务器处理完图片，然后再由前端web服务器把图片post到到[图片1]、[图片2]…[图片N]其中的一个，图片服务器接收到post过来的图片，然后把图片写入到本地磁盘并返回对应成功状态码。前端web服务器根据返回状态码决定对应操作，如果成功的话，处理生成各尺寸的缩略图、打水印，把图片服务器对应的ID和对应图片路径写入DB数据库。2)上传控制我们需要调节上传时，只需要修改web服务器post到的目的图片服务器的ID，就可以控制上传到哪台图片存储服务器,对应的图片存储服务器只需要安装nginx同时提供一个python或者php服务接收并保存图片，如果不想不想开启python或者php服务，也可以编写一个nginx扩展模块。3)用户访问流程用户访问页面的时候，根据请求图片的URL到对应图片服务器去访问图片。如：http://imgN.xxx.com/image1.jpg 此阶段的图片服务器架构，增加了负载均衡和分布式图片存储，能够在一定程度上解决并发访问量高和存储量大的问题。负载均衡在有一定财力的情况下可以考虑F5硬负载，当然也可以考虑使用开源的LVS软负载(同时还可开启缓存功能)。此时将极大提升访问的并发量，可以根据情况随时调配服务器。当然此时也存在一定的瑕疵，那就是可能在多台Squid上存在同一张图片，因为访问图片时可能第一次分到squid1，在LVS过期后第二次访问到squid2或者别的，当然相对并发问题的解决，此种少量的冗余完全在我们的允许范围之内。在该系统架构中二级缓存可以使用squid也可以考虑使用varnish或者trafficserver，对于cache的开源软件选型要考率以下几点 1）性能：varnish本身的技术上优势要高于squid，它采用了“VisualPageCache”技术，在内存的利用上，Varnish比Squid具有优势，它避免了Squid频繁在内存、磁盘中交换文件，性能要比Squid高。varnish是不能cache到本地硬盘上的。还有强大的通过Varnish管理端口，可以使用正则表达式快速、批量地清除部分缓存。nginx是用第三方模块ncache做的缓冲，其性能基本达到varnish，但在架构中nginx一般作为反向（静态文件现在用nginx的很多，并发能支持到2万+）。在静态架构中，如果前端直接面对的是cdn活着前端了4层负载的话，完全用nginx的cache就够了。 2）避免文件系统式的缓存，在文件数据量非常大的情况下，文件系统的性能很差，像squid,nginx的proxy_store,proxy_cache之类的方式缓存，当缓存的量级上来后，性能将不能满足要求。开源的trafficserver直接用裸盘缓存，是一个不错的选择，国内大规模应用并公布出来的主要是淘宝，并不是因为它做的差，而是开源时间晚。TrafficServer在Yahoo内部使用了超过4年，主要用于CDN服务，CDN用于分发特定的HTTP内容，通常是静态的内容如图片、JavaScript、CSS。当然使用leveldb之类的做缓存，我估计也能达到很好的效果。 3）稳定性：squid作为老牌劲旅缓存，其稳定性更可靠一些，从我身边一些使用者反馈来看varnish偶尔会出现crash的情况。TrafficServer在雅虎目前使用期间也没有出现已知的数据损坏情况，其稳定性相对也比较可靠，对于未来我其实更期待TrafficServer在国内能够拥有更多的用户。 以上图片服务架构设计消除了早期的NFS依赖以及单点问题，时能够均衡图片服务器的空间，提高了图片服务器的安全性等问题，但是又带来一个问题是图片服务器的横向扩展冗余问题。只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是7200转的还是15000转的，实际表现差别就很大。至于文件系统选择xfs、ext3、ext4还是reiserFs，需要做一些性能方面的测试，从官方的一些测试数据来看，reiserFs更适合存储一些小图片文件。创建文件系统的时候Inode问题也要加以考虑，选择合适大小的inodesize，因为Linux为每个文件分配一个称为索引节点的号码inode，可以将inode简单理解成一个指针，它永远指向本文件的具体存储位置。一个文件系统允许的inode节点数是有限的，如果文件数量太多，即使每个文件都是0字节的空文件，系统最终也会因为节点空间耗尽而不能再创建文件，因此需要在空间和速度上做取舍，构造合理的文件目录索引。 云存储阶段阿里云存储服务(OpenStorageService，简称OSS)，是阿里云对外提供的海量，安全，低成本，高可靠的云存储服务。用户可以通过简单的REST接口，在任何时间、任何地点上传和下载数据，也可以使用WEB页面对数据进行管理。同时，OSS提供Java、Python、PHPSDK，简化用户的编程。基于OSS，用户可以搭建出各种多媒体分享网站、网盘、个人企业数据备份等基于大规模数据的服务。在以下图片云存储主要以阿里云的云存储OSS为切入点介绍，上图为OSS云存储的简单架构示意图。 真正意义上的“云存储”，不是存储而是提供云服务，使用云存储服务的主要优势有以下几点：1)用户无需了解存储设备的类型、接口、存储介质等。2)无需关心数据的存储路径。3)无需对存储设备进行管理、维护。4)无需考虑数据备份和容灾5)简单接入云存储，尽情享受存储服务。 架构模块组成1）KVEngineOSS中的Object源信息和数据文件都是存放在KVEngine上。在6.15的版本，VEngine将使用0.8.6版本，并使用为OSS提供的OSSFileClient。 2）Quota此模块记录了Bucket和用户的对应关系，和以分钟为单位的Bucket资源使用情况。Quota还将提供HTTP接口供Boss系统查询。 3）安全模块安全模块主要记录User对应的ID和Key，并提供OSS访问的用户验证功能。 OSS术语名词汇 1）AccessKeyID&AccessKeySecret（API密钥）用户注册OSS时，系统会给用户分配一对AccessKeyID&AccessKeySecret，称为ID对，用于标识用户，为访问OSS做签名验证。 2）ServiceOSS提供给用户的虚拟存储空间，在这个虚拟空间中，每个用户可拥有一个到多个Bucket。 3）BucketBucket是OSS上的命名空间；Bucket名在整个OSS中具有全局唯一性，且不能修改；存储在OSS上的每个Object必须都包含在某个Bucket中。一个应用，例如图片分享网站，可以对应一个或多个Bucket。一个用户最多可创建10个Bucket，但每个Bucket中存放的Object的数量和大小总和没有限制，用户不需要考虑数据的可扩展性。4）Object在OSS中，用户的每个文件都是一个Object，每个文件需小于5TB。Object包含key、data和usermeta。其中，key是Object的名字；data是Object的数据；usermeta是用户对该object的描述。其使用方式非常简单,如下为javasdk：JavaCode复制内容到剪贴板OSSClient ossClient = new OSSClient(accessKeyId,accessKeySecret); PutObjectResult result = ossClient.putObject(bucketname, bucketKey, inStream, new ObjectMetadata()); 执行以上代码即可将图片流上传至OSS服务器上。图片的访问方式也非常简单其url为：http://bucketname.oss.aliyuncs.com/bucketKey 分布式文件系统用分布式存储有几个好处，分布式能自动提供冗余，不需要我们去备份，担心数据安全，在文件数量特别大的情况下，备份是一件很痛苦的事情，rsync扫一次可能是就是好几个小时，还有一点就是分布式存储动态扩容方便。当然在国内的其他一些文件系统里，TFS（http://code.taobao.org/p/tfs/src/）和FASTDFS也有一些用户，但是TFS的优势更是针对一些小文件存储，主要是淘宝在用。另外FASTDFS在并发高于300写入的情况下出现性能问题，稳定性不够友好。OSS存储使用的是阿里云基于飞天5k平台自主研发的高可用，高可靠的分布式文件系统盘古。分布式文件系统盘古和Google的GFS类似，盘古的架构是Master-Slave主从架构，Master负责元数据管理，Sliave叫做ChunkServer，负责读写请求。其中Master是基于Paxos的多Master架构，一个Master死了之后，另外一个Master可以很快接过去，基本能够做到故障恢复在一分钟以内。文件是按照分片存放，每个会分三个副本，放在不同的机架上，最后提供端到端的数据校验。 HAPROXY负载均衡基于haproxy的自动hash架构,这是一种新的缓存架构，由nginx作为最前端，代理到缓存机器。nginx后面是缓存组，由nginx经过urlhash后将请求分到缓存机器。这个架构方便纯squid缓存升级，可以在squid的机器上加装nginx。nginx有缓存的功能，可以将一些访问量特大的链接直接缓存在nginx上，就不用经过多一次代理的请求，能够保证图片服务器的高可用、高性能。比如favicon.ico和网站的logo。负载均衡负责OSS所有的请求的负载均衡，后台的http服务器故障会自动切换，从而保证了OSS的服务不间断。 CDN阿里云CDN服务是一个遍布全国的分布式缓存系统，能够将网站文件（如图片或JavaScript代码文件）缓存到全国多个城市机房中的服务器上，当一个用户访问你的网站时，会就近到靠近TA的城市的服务器上获取数据，这样最终用户访问你的服务速度会非常快。阿里云CDN服务在全国部署超过100个节点，能提供给用户优良的网络加速效果。当网站业务突然爆发增长时，无需手忙脚乱地扩容网络带宽，使用CDN服务即可轻松应对。和OSS服务一样，使用CDN，需要先在aliyun.com网站上开通CDN服务。开通后，需要在网站上的管理中心创建你的distribution（即分发频道），每个distribution由两个必须的部分组成：distributionID和源站地址。使用阿里云OSS和CDN可以非常方便的针对每个bucket进行内容加速，因为每个bucket对应一个独立的二级域名，针对每个文件进行CDN删除，简单、经济地解决服务的存储和网络问题，毕竟大多数网站或应用的存储和网络带宽多半是被图片或视频消耗掉的。从整个业界来看，最近这样的面向个人用户的云存储如国外的DropBox和Box.net非常受欢迎，国内的云存储目前比较不错的主要有七牛云存储和又拍云存储。 上传下载分而治之图片服务器的图片下载比例远远高于上传比例，业务逻辑的处理也区别明显，上传服器对图片重命名，记录入库信息，下载服务器对图片添加水印、修改尺寸之类的动态处理。从高可用的角度，我们能容忍部分图片下载失败，但绝不能有图片上传失败，因为上传失败，意味着数据的丢失。上传与下载分开，能保证不会因下载的压力影响图片的上传，而且还有一点，下载入口和上传入口的负载均衡策略也有所不同。上传需要经过QuotaServer记录用户和图片的关系等逻辑处理，下载的逻辑处理如果绕过了前端缓存处理，穿透后端业务逻辑处理，需要从OSS获取图片路径信息。近期阿里云会推出基于CDN就近上传的功能，自动选择离用户最近的CDN节点，使得数据的上传下载速度均得到最优化。相较传统IDC，访问速度提升数倍。 图片防盗链处理如果服务不允许防盗链，那么访问量会引起带宽、服务器压力等问题。比较通用的解决方案是在nginx或者squid反向代理软件上添加referACL判断，OSS也提供了基于refer的防盗链技术。当然OSS也提供了更为高级的URL签名防盗链，其其实现思路如下： 首先，确认自己的bucket权限是private，即这个bucket的所有请求必须在签名认证通过后才被认为是合法的。然后根据操作类型、要访问的bucket、要访问的object以及超时时间，动态地生成一个经过签名的URL。通过这个签名URL，你授权的用户就可以在该签名URL过期时间前执行相应的操作。 签名的Python代码如下： 复制代码代码如下:h=hmac.new(“OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV”,“GET\n\n\n1141889120\n/oss-example/oss-api.jpg”,sha);urllib.quote_plus(base64.encodestring(h.digest()).strip()); 其中method可以是PUT、GET、HEAD、DELETE中的任意一种；最后一个参数“timeout”是超时的时间，单位是秒。一个通过上面Python方法，计算得到的签名URL为：http://oss-example.oss-cn-hangzhou.aliyuncs.com/oss-api.jpg?OSSAccessKeyId=44CF9590006BF252F707&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D 通过这种动态计算签名URL的方法，可以有效地保护放在OSS上的数据，防止被其他人盗链。 图片编辑处理API对于在线图片的编辑处理，GraphicsMagick（GraphicsMagick(http://www.graphicsmagick.org/)）对于从事互联网的技术人员应该不会陌生。GraphicsMagick是从ImageMagick5.5.2分支出来的，但是现在他变得更稳定和优秀，GM更小更容易安装、GM更有效率、GM的手册非常丰富GraphicsMagick的命令与ImageMagick基本是一样的。 GraphicsMagick提供了包括裁、缩放、合成、打水印、图像转换、填充等非常丰富的接口API,其中的开发包SDK也非常丰富，包括了JAVA(im4java)、C、C++、Perl、PHP、Tcl、Ruby等的调用，支持超过88中图像格式，包括重要的DPX、GIF、JPEG、JPEG-2000、PNG、PDF、PNM和TIFF，GraphicsMagick可以再绝大多数的平台上使用，Linux、Mac、Windows都没有问题。但是独立开发这些图片处理服务，对服务器的IO要求相对要高一些，而且目前这些开源的图片处理编辑库，相对来说还不是很稳定，笔者在使用GraphicsMagick的时候就遇到了tomcat进程crash情况，需要手动重启tomcat服务。 阿里云目前已经对外开放图片处理API,包括了大多数常用处理解决方案：缩略图、打水印、文字水印、样式、管道等。开发者可以非常方便的使用如上图片处理方案，希望越来越多的开发者能够基于OSS开放出更多优秀的产品。
飞天项目的整体架构，最底层基础架构是由通用服务器组成的Linux集群，没有使用高端的服务器和存储。飞天提供功能的方式是通过服务的方式，下图中所有蓝色的框（指各类云计算服务）都是对外提供服务的窗口，但这里蓝色的框并不代表所有阿里云提供的服务，还有许多其他的服务没有包括。最上层，飞天项目是阿里云整个产品和服务的技术基础，上面是各种各样的应用。飞天平台上强调的是做多租户，因为众所周知云计算带来的好处就是弹性，另外一个就是需要帮助大家降低成本。下面这张图是飞天的体系结构介绍。整个的飞天系统，最基础的两大系统，盘古和伏羲。如果大家之前了解过这方面的资料，应该对这张图非常熟悉。飞天基础系统上承载着多个云产品，ECS/SLB、OSS、OTS、OSPS、包括ODPS的系统。安全机制在飞天及飞天承载的云产品中起着至关重要的作用。主要的工作包括几个方面，一个是访问控制机制另一方面是安全沙箱.访问控制机制包括从盘古文件的访问、读取和认证机构，还有ODPS、OTS、OSS等系统基于飞天做，飞天会帮它们做所有上层的安全措施基础机制支撑工作。尤其是ODPS系统，其所有的访问控制机制和安全沙箱的系统，都是由飞天安全提供机制来支持的。今天我们要讲的议题，首先会从攻击者的角度看一下云上的计算系统有哪些AttackSurfaces可以利用.然后看一下目前开源的产品，比较著名的产品从这个角度来看是如何解决安全问题的。以及linux系统提供了那些安全机制可供安全沙箱使用。最后，我们具体了解一下飞天安全沙箱的方案。首先，我们看一下典型的云计算环境中，为支撑用户代码的运行，从上到下的结构。通常为了让用户代码能够执行高级语言，我们都会有一层高级语言的虚拟机,比如JVM,Cpython。我们以后有些系统会跑JS，这里对应的是V8。这些虚拟器通常是C语言来开发的，相对来说是一个独立的系统，再下一层是Libc的库，这个对应的是C语言的so。再往下一层是LinuxKernel。再往下其实还有，如果是说这个系统用的是虚机，往下还会有物理机，本次分享不讨论这个问题。对于这样的系统来说，如果Usercode的恶意代码，为了拿到LinuxKernel的root权限需要一步步的渗透。入侵者如果想要到达最终目标，首先要突破高级语言虚拟机的安全防护，比如Java的SecurityManager机制。不过根据最近几年的漏洞情况判断，JVM安全沙箱对入侵来说是并没有太大的难度，可以假定一定会被突破。通过JVM提供的Navtive调用，它可以直接调用到Libc。Libc对入侵者来说，主要目的是要拿到当前进程的权限。最后一层是LinuxKernel，我们在云计算平台上来说，跑用户代码的进程不会是root，大家想像一下也知道，root不会给最终用户区跑这个代码的。当入侵者真的通过前基层的安全防护机制，并成功攻破root权限，那么这台机器已经被他控制在手里了。我们可以想像一下，在云计算这样一个集群里面，我们通常来说会跑成千上万的实例，如果我们把这个实例数放到最大，这样的代码被执行完之后，是不是整个集群所有机器的权限都可以拿到了。这是非常可怕的事情。就算我们在某一方面可以控制用户提交数量，云计算平台上通常会使用相同一台机器同时处理多个用户，如果有一台机器被用户集权到root，上面的所有数据和密钥，对于入侵者来说都是可见的了。接下来我们看一下，业内有一些做得比较好的安全产品，在安全方面沙箱方面如何解决的用户隔离问题。首先我们看一下Docker目前使用哪些机制，这张图主要是使用了三个纬度，有两个纬度产生了LXC，使用了Namespaces，Namespaces它可以在多个方面实现一定的隔离能力。这个能力需要在2.6.x以后才能部分开始使用。Cgroups机制保证操作系统资源的合理管理。另外，Docker启用了AUSF的分层文件系统。传统文件系统，我们可以认为是纵向的文件系统，你写哪个文件，这个文件一直到硬件，而AUSF是可以进行叠加的。一层层的文件夹叠加，会映射成一个相同的文件夹。Docker里面，最下面的image用来做系统环境，中间会做APP，最上面是用户运行期的东西，这些东西会被Docker封装成一层层，实现了类似于集装箱式的部署能力。对于Docker来说，对一个攻击者来说，眼中看到的Docker应用有哪些东西？从刚才的图上也是类似的，整个系统有一个Dockercontainer，右边是DockerEngine。如果你在Docker上直接部署C进程，下面两层就是C的程序。对于恶意用户来说，如果想得到所在机器的root权限，要突破你在Iibc上做的措施，还需要突破kernel中seccomp-bpf，这是kernel提供的一个安全机制，允许你定义某一个进程所能进行的系统过滤。第第三层攻破，seccomp-bpf可以进行额外的安全判断。你如果把这个也突破了，其实这台机器也直接root掉了。 接下来我们看googlechrome的沙箱。Chrome使用过SUID/Namespacessandbox,这也是对linxcontainer机制的利用。使用过seccomp-legacy。在没有seccomp-bpf之前google使用seccomp-legacy。seccomp-legacy使用限制非常大。也同样使用过seccomp-bpf。我们刚才看了两个业内的安全产品，可以简单的总结一下，对于沙箱来说，我们有哪些安全机制可以使用？参考这张图，首先对于JVM来说，我们可以用JavasecurityManager以及Classloader机制。如果是LinuxKernel，那么我们还可以直接利用KernelNamespaces，Cgroup，Chroot、umount。这些东西在LXC已经封装好了可以用，而且通常它们在一起使用才可以产生比较好的效果。然后是aufs，2.6才开始支持。Seccomp-bpf是3.5，如果版本不够你就要使用其他方案来做内核层的一些过滤了。另外一个角度，对云计算上的安全沙箱来说有哪些层次可以做防御？JVM内的防御是否有必要？Java的安全沙箱攻破的难度不是很大，它是不是不要了？刚才我们说了，安全沙箱没有绝对安全的设计，如何在安全上做到尽可能可靠的防护？多层防御可以有效提高安全防护能力。第二是进层隔离，用于提供安全机制。第三层要在kernelspace里面要有安全过虑。 前面做完了，基于现有的安全机制来说，至少可以认为在目前，可以直接使用的防护措施就这些了。刚才我们看到了一些安全机制，接下来看看飞天安全在沙箱方面使用哪些机制？其实前面我们说的这些，该用的都用到了。 飞天安全沙箱，是这样的一个系统。简单来看，这张图和我们之前的两张图有相似的地方。最终的方案，我们方案融合了前两个的优点。我们这一层的Usercode可以放到C语言下进行，Iibc可以有一些拦截。这个地方是基于IPC的，所以你在当前进程要做的破坏或者说做的事情，是无法影响到另一个进程的。最后是Linuxcontainer，我们有一层内核过滤机制来保证。我们今天的分享还是比较聚焦的，就是讲沙箱和安全机制。我们看了一些业内主要的安全产品实现，以及它使用的安全机制。最后针对一个具体的案例-飞天安全沙箱，我们了解了该如何实现融合多种安全机制来实现与著名安全产品相同等级防护能力的安全沙箱。
网站需要备案，这是地球人都知道的。可是，网站还要公安备案你知道吗?如果你的网站没有备案，应该就不用再公安备案了，如果你的网站已经备案过，现在得进行公安备案了。 其实，几个月前我就知道了公安备案，不过那时候不知道要怎么操作。前段时间我收到阿里云的邮件通知，说要审核备案主体信息，看是否是本人，那个时候我就一直在等。 前几天我收到一条短信，说请到公安备案网站进行备案，如果不备案将作为非法网站给关闭了。看到这样的短信，我以为是骗子就没有理。今天早接到一个电话我给挂了，然后收到同样的信息叫我进行网站公安备案。 我便打电话问下，说是我们本地的网警，要我登录网站进行备案。听完后，我便登录网站进行备案，而且花了几十分钟给搞好了。下面就教大家如何给网站公安备案： 1，打开全国公安机关网站www.beian.gov.cn注册一个帐号登录 2，登录后会提示填写开办主体管理，如果没有提示登录后点击左边的菜单就行 3，填写主体相关的信息，比如个人，姓名，身份证等信息，然后保存 4，找到左边菜单新办网站申请，这点不用填写，直接点击下一步 5，填写网站基本信息，包括网站开通日期，名称等，域名证书去域名网站下载，服务商相关问题可以问客服，IP添加不了的换火狐浏览器就行，然后点击下一步 6，网站负责人只需要把同主体负责人信息打上勾就行了，网站应急联系人也是一样 7，然后出现的是互联网安全告知书，同意提交出就能看到审核状态 8，等几天的时间备案审核通过后，在后台主页已备案国网站里点击搜索按钮 9，点击复制备案编号的HTML代码 10，把代码复制到你的网站底部文件代码里 这时候在你的网站底部就能看到网站公安备案号和图标了，而且必须是点击能打开了，打开后能看到网站的备案信息。这样，如果你网站以后有什么违法信息别人就可以通过此来举报。公安备案，也只是防止一些违法的网站，也是有必要弄的。
王自如，ZEALER创始人。从2010年3月开始做数码产品的开箱视频，之后拓展到科技评论。近日，科技测评人王自如做客“腾讯云会客厅”，与腾讯云副总裁曾佳欣展开对话，跟大家分享了他的创业经验和大流量下的技术支持。ZEALER的IT变迁作为一家科技视频媒体，ZEALER不仅仅提供测评视频，还有机器人、音箱、键盘等科技酷品的体验，以及科技大佬类的专访。其商业模式是靠电商，靠后端的服务赚钱，输出一种年轻人的生活方式来标榜自己，让相关产品获得用户的喜爱。王自如强调，所有的内容产出虽然围绕着科技这么一个主题，但其实输出的是一种文化和价值观，让科技把生活变得更美好。ZEALER的商业模式需要他们进行很多的思考，IT的支持需求自然是省心——高效、自动化、智能化。王自如介绍了ZEALER的IT变迁。ZEALER刚成立初期，采用传统的IDC机房托管，自行采购服务器，搭建出最初的网站技术架构，运行在Linux操作系统上面。随着公司业务的快速发展，网站的访问量也越来越高，ZEALER的服务器资源已经无法满足高峰期的访问量，网站访问不是很稳定。为了解决问题，ZEALER采购了新的服务器，并在同期引入CDN服务，在一定程度上缓解了网站高峰期的访问压力。然而，ZEALER又发现，传统IDC机房托管的方式，在服务器资源进行扩容时有很多的不便利。采购的服务器需要重新申请进入机房，办理手续也非常的繁琐。经过谨慎评估后，ZEALER决定把网站迁移至云平台，以便能在未来业务高速增长的情况下，保证网站底层架构能够稳定地支撑发展需要。王自如眼中的云计算对于云计算，王自如认为，近些年来云计算已经成为了一种技术趋势，OpenStack、Docker等开源技术的不断进步，使得创业项目可以更好地运行在云平台上，更合理地分配云计算资源，传统的技术架构正在逐步迁移到新的云架构。不过，王自如更关注的还是云计算怎么解决实际的需求，他认为这是核心问题。对于ZEALER来说，他希望云服务能够为公司提供更广阔的上升空间。ZEALER测评视频虽然有时上线周期较长，但一上线短时间内就是几十上百万的IP访问。所以，在用户量高速增长时，如何拥有一个稳定、安全的服务器，无疑是最关键的问题。ZEALER其实跟很多视频播放平台合作过，最后落户于同处深圳的腾讯云。“一方面是因为腾讯是我们的投资人，另一方面也是因为换了之后，团队的响应速度和技术底层的支持确实给我们的力度是最大的，也是最稳定的。我们做测评这么多年，其实我们也在测评各家服务平台，对比完之后发现，我们最终自然地过渡到腾讯云，是一个理性选择的结果。”王自如给出了选择腾讯云的原因。对于云上的数据安全，王自如认为，云平台经过这些年的发展，其数据安全性这块已经做得很好，并且都有相对较为完善的冷热备份数据的解决方案。如果云资源出现问题，也都拥有及时的报警系统来提示ZEALER的技术人员快速解决相关问题。访谈中，王自如也分享了ZEALER技术团队曾经遇到的问题。比如半夜的时候视频发布突遇视频不能播放的问题，或者是分享的功能不能实现。腾讯云的伙伴都会立刻更改代码，迅速做出响应，保证用户的体验。此外，王自如还表示，ZEALER在做内容，需要依托腾讯云的服务器和视频平台来让ZEALER把东西传播出去，也需要依托更多的品牌商和合作伙伴，来让ZEALER把面拓广。未来规划王自如认为，互联网是一个降低信息壁垒的工具，是一种沟通渠道，是一种效率提升的方式，所以还是要从线上走到线下，现在没有哪家互联网公司是纯依托线上赚钱的。对于小型创业公司来说，最现实的就是如何去善用每种工具，出发点还是核心的生活需求，就是这东西真的能够带来价值，有用才行。无论O2O、支付工具、视频还是云服务，都是提供这种价值的途径和工具之一，能够通过排列组合，把这个服务打包好才是最重要的。对于ZEALER而言，目前的挑战主要还是在大并发量和多平台互动的问题，还需要积累经验。另外，数据统计的能力也还需要再提高。由此，ZEALER未来希望基于云计算建立起行业内领先的科技电子类产品的大数据;希望能站在大数据的角度，对每一款产品进行精准的数据画像，去帮助大家理解和思考科技电子产品，并能提供有价值购买决策。关于大数据平台，目前的互联网公司都是使用比较成熟的开源产品来研发，不过，王自如希望未来有更成熟的云服务解决方案可以采用。
新浪微博：史上最大的Redis集群TapeisDead，DiskisTape，FlashisDisk，RAMLocalityisKing.—JimGrayRedis不是比较成熟的memcache或者Mysql的替代品，是对于大型互联网类应用在架构上很好的补充。现在有越来越多的应用也在纷纷基于Redis做架构的改造。首先简单公布一下Redis平台实际情况：2200+亿commands/day5000亿Read/day500亿Write/day18TB+Memory500+Serversin6IDC2000+instances应该是国内外比较大的Redis使用平台，今天主要从应用角度谈谈Redis服务平台。Redis使用场景1.Counting（计数）计数的应用在另外一篇文章里较详细的描述，计数场景的优化http://www.xdata.me/?p=262这里就不多加描述了。可以预见的是，有很多同学认为把计数全部存在内存中成本非常高，我在这里用个图表来表达下我的观点：很多情况大家都会设想纯使用内存的方案会很有很高成本，但实际情况往往会有一些不一样：COST，对于有一定吞吐需求的应用来说，肯定会单独申请DB、Cache资源，很多担心DB写入性能的同学还会主动将DB更新记入异步队列，而这三块的资源的利用率一般都不会太高。资源算下来，你惊异的发现：反而纯内存的方案会更精简！KISS原则，这对于开发是非常友好的，我只需要建立一套连接池，不用担心数据一致性的维护，不用维护异步队列。Cache穿透风险，如果后端使用DB，肯定不会提供很高的吞吐能力，cache宕机如果没有妥善处理，那就悲剧了。大多数的起始存储需求，容量较小。2.Reversecache（反向cache）面对微博常常出现的热点，如最近出现了较为火爆的短链，短时间有数以万计的人点击、跳转，而这里会常常涌现一些需求，比如我们向快速在跳转时判定用户等级，是否有一些账号绑定，性别爱好什么的，已给其展示不同的内容或者信息。普通采用memcache+Mysql的解决方案，当调用id合法的情况下，可支撑较大的吞吐。但当调用id不可控，有较多垃圾用户调用时，由于memcache未有命中，会大量的穿透至Mysql服务器，瞬间造成连接数疯长，整体吞吐量降低，响应时间变慢。这里我们可以用redis记录全量的用户判定信息，如stringkey:uidint:type，做一次反向的cache，当用户在redis快速获取自己等级等信息后，再去Mc+Mysql层去获取全量信息。如图：当然这也不是最优化的场景，如用Redis做bloomfilter，可能更加省用内存。3.Top10list产品运营总会让你展示最近、最热、点击率最高、活跃度最高等等条件的toplist。很多更新较频繁的列表如果使用MC+MySQL维护的话缓存失效的可能性会比较大，鉴于占用内存较小的情况，使用Redis做存储也是相当不错的。4.LastIndex用户最近访问记录也是redislist的很好应用场景，lpushlpop自动过期老的登陆记录，对于开发来说还是非常友好的。5.RelationList/MessageQueue这里把两个功能放在最后，因为这两个功能在现实问题当中遇到了一些困难，但在一定阶段也确实解决了我们很多的问题，故在这里只做说明。MessageQueue就是通过list的lpop及lpush接口进行队列的写入和消费，由于本身性能较好也能解决大部分问题。6.FasttransactionwithLuaRedis的Lua的功能扩展实际给Redis带来了更多的应用场景，你可以编写若干command组合作为一个小型的非阻塞事务或者更新逻辑，如：在收到message推送时，同时1.给自己的增加一个未读的对话2.给自己的私信增加一个未读消息3.最后给发送人回执一个完成推送消息，这一层逻辑完全可以在RedisServer端实现。但是，需要注意的是Redis会将luascript的全部内容记录在aof和传送给slave，这也将是对磁盘，网卡一个不小的开销。7.InsteadofMemcache很多测试和应用均已证明，在性能方面Redis并没有落后memcache多少，而单线程的模型给Redis反而带来了很强的扩展性。在很多场景下，Redis对同一份数据的内存开销是小于memcache的slab分配的。Redis提供的数据同步功能，其实是对cache的一个强有力功能扩展。Redis使用的重要点1.rdb/aofBackup!我们线上的Redis95%以上是承担后端存储功能的，我们不仅用作cache，而更为一种k-v存储，他完全替代了后端的存储服务（MySQL），故其数据是非常重要的，如果出现数据污染和丢失，误操作等情况，将是难以恢复的。所以备份是非常必要的！为此，我们有共享的hdfs资源作为我们的备份池，希望能随时可以还原业务所需数据。2.Smallitem&Smallinstance!由于Redis单线程（严格意义上不是单线程，但认为对request的处理是单线程的）的模型，大的数据结构list,sortedset,hashset的批量处理就意味着其他请求的等待，故使用Redis的复杂数据结构一定要控制其单key-struct的大小。另外，Redis单实例的内存容量也应该有严格的限制。单实例内存容量较大后，直接带来的问题就是故障恢复或者Rebuild从库的时候时间较长，而更糟糕的是，Redisrewriteaof和saverdb时，将会带来非常大且长的系统压力，并占用额外内存，很可能导致系统内存不足等严重影响性能的线上故障。我们线上96G/128G内存服务器不建议单实例容量大于20/30G。3.BeenAvailable!业界资料和使用比较多的是Redissentinel（哨兵）http://www.huangz.me/en/latest/storage/redis_code_analysis/sentinel.htmlhttp://qiita.com/wellflat/items/8935016fdee25d4866d92000行C实现了服务器状态检测，自动故障转移等功能。但由于自身实际架构往往会复杂，或者考虑的角度比较多，为此@许琦eryk和我一同做了hypnos项目。hypnos是神话中的睡神，字面意思也是希望我们工程师无需在休息时间处理任何故障。:-)其工作原理示意如下：Talkischeap,showmeyourcode!稍后将单独写篇博客细致讲下Hypnos的实现。4.InMemoryornot?发现一种情况，开发在沟通后端资源设计的时候，常常因为习惯使用和错误了解产品定位等原因，而忽视了对真实使用用户的评估。也许这是一份历史数据，只有最近一天的数据才有人进行访问，而把历史数据的容量和最近一天请求量都抛给内存类的存储现实是非常不合理的。所以当你在究竟使用什么样的数据结构存储的时候，请务必先进行成本衡量，有多少数据是需要存储在内存中的？有多少数据是对用户真正有意义的。因为这其实对后端资源的设计是至关重要的，1G的数据容量和1T的数据容量对于设计思路是完全不一样的Plansinfuture?1.slavesync改造全部改造线上master-slave数据同步机制，这一点我们借鉴了MySQLReplication的思路，使用rdb+aof+pos作为数据同步的依据，这里简要说明为什么官方提供的psync没有很好的满足我们的需求：假设A有两个从库B及C，及A`—B&C，这时我们发现masterA服务器有宕机隐患需要重启或者A节点直接宕机，需要切换B为新的主库，如果A、B、C不共享rdb及aof信息，C在作为B的从库时，仍会清除自身数据，因为C节点只记录了和A节点的同步状况。故我们需要有一种将A`–B&C结构切换切换为A`–B`–C结构的同步机制，psync虽然支持断点续传，但仍无法支持master故障的平滑切换。实际上我们已经在我们定制的Redis计数服务上使用了如上功能的同步，效果非常好，解决了运维负担，但仍需向所有Redis服务推广，如果可能我们也会向官方Redis提出相关syncslave的改进。2.更适合redis的name-systemOrproxy细心的同学发现我们除了使用DNS作为命名系统，也在zookeeper中有一份记录，为什么不让用户直接访问一个系统，zk或者DNS选择其一呢？其实还是很简单，命名系统是个非常重要的组件，而dns是一套比较完善的命名系统，我们为此做了很多改进和试错，zk的实现还是相对复杂，我们还没有较强的把控粒度。我们也在思考用什么做命名系统更符合我们需求。3.后端数据存储大内存的使用肯定是一个重要的成本优化方向，flash盘及分布式的存储也在我们未来计划之中。二、Pinterest：Reids维护上百亿的相关性Pinterest已经成为硅谷最疯故事之一，在2012年，他们基于PC的业务增加1047%，移动端采用增加1698%，该年3月其独立访问数量更飙升至533亿。在Pinterest，人们关注的事物以百亿记——每个用户界面都会查询某个board或者是用户是否关注的行为促成了异常复杂的工程问题。这也让Redis获得了用武之地。经过数年的发展，Pinterest已经成为媒体、社交等多个领域的佼佼者，其辉煌战绩如下：获得的推荐流量高于Google+、YouTube及LinkedIn三者的总和与Facebook及Twitter一起成为最流行的三大社交网络参考Pinterest进行购买的用户比其它网站更高如您所想，基于其独立访问数，Pinterest的高规模促成了一个非常高的IT基础设施需求。1.通过缓存来优化用户体验近日，Pinterest工程经理AbhiKhune对其公司的用户体验需求及Redis的使用经验进行了分享。即使是滋生的应用程序打造者，在分析网站的细节之前也不会理解这些特性，因此先大致的理解一下使用场景：首先，为每个粉丝进行提及到的预检查；其次，UI将准确的显示用户的粉丝及关注列表分页。高效的执行这些操作，每次点击都需要非常高的性能架构。不能免俗，Pinterest的软件工程师及架构师已经使用了MySQL及memcache，但是缓存解决方案仍然达到了他们的瓶颈；因此为了拥有更好的用户体验，缓存必须被扩充。而在实际操作过程中，工程团队已然发现缓存只有当用户sub-graph已经在缓存中时才会起到作用。因此。任何使用这个系统的人都需要被缓存，这就导致了整个图的缓存。同时，最常见的查询“用户A是否关注了用户B”的答案经常是否定的，然而这却被作为了缓存丢失，从而促成一个数据库查询，因此他们需要一个新的方法来扩展缓存。最终，他们团队决定使用Redis来存储整个图，用以服务众多的列表。2.使用Redis存储大量的Pinterest列表Pinterest使用了Redis作为解决方案，并将性能推至了内存数据库等级，为用户保存多种类型列表：关注者列表你所关注的board列表粉丝列表关注你board的用户列表某个用户中board中你没有关注的列表每个board的关注者及非关注者Redis为其7000万用户存储了以上的所有列表，本质上讲可以说是储存了所有粉丝图，通过用户ID分片。鉴于你可以通过类型来查看以上列表的数据，分析概要信息被用看起来更像事务的系统储存及访问。Pinterest当下的用户like被限制为10万，初略进行统计：如果每个用户关注25个board，将会在用户及board间产生17.5亿的关系。同时更加重要的是，这些关系随着系统的使用每天都会增加。3.Pinterest的Reids架构及运营通过Pinterest的一个创始人了解到，Pinterest开始使用Python及订制的Django编写应用程序，并一直持续到其拥有1800万用户级日410TB用户数据的时候。虽然使用了多个存储对数据进行储存，工程师根据用户id使用了8192个虚拟分片，每个分片都运行在一个RedisDB之上，同时1个Redis实例将运行多个RedisDB。为了对CPU核心的充分使用，同一台主机上同时使用多线程和单线程Redis实例。鉴于整个数据集运行在内存当中，Redis在AmazonEBS上对每秒传输进来的写入都会进行持久化。扩展主要通过两个方面进行：第一，保持50%的利用率，通过主从转换，机器上运行的Redis实例一半会转译到一个新机器上；第二，扩展节点和分片。整个Redis集群都会使用一个主从配置，从部分将被当做一个热备份。一旦主节点失败，从部分会立刻完成主的转换，同时一个新的从部分将会被添加，ZooKeeper将完成整个过程。同时他们每个小时都会在AmazonS3上运行BGsave做更持久的储存——这项Reids操作会在后端进行，之后Pinterest会使用这些数据做MapReduce和分析作业。 三、Viacom：Redis在系统中的用例盘点Viacom是全球最大的传媒集体之一，同时也遭遇了当下最大的数据难题之一：如何处理日益剧增的动态视频内容。着眼这一挑战的上升趋势，我们会发现：2010年世界上所有数据体积达到ZB级，而单单2012这一年，互联网产生的数据就增加了2.8个ZB，其中大部分的数据都是非结构化的，包括了视频和图片。覆盖MVN（以前称为MTVNetworks、Paramount及BET），Viacom是个名副其实的传媒巨头，支持众多人气站点，其中包括TheDailyShow、osh.0、SouthParkStudios、GameTrailers.com等。作为媒体公司，这些网站上的文档、图片、视频短片都在无时无刻的更新。长话短说，下面就进入Viacom高级架构师MichaelVenezia分享的Redis实践：1.Viacom的网站架构背景对于Viacom，横跨多个站点传播内容让必须专注于规模的需求，同时为了将内容竟可能快的传播到相应用户，他们还必须聚焦内容之间的关系。然而即使TheDailyShow、Nickelodeon、Spike或者是VH1这些单独的网站上，日平均PV都可以达到千万，峰值时流量更会达到平均值的20-30倍。同时基于对实时的需求，动态的规模及速度已成为架构的基础之一。除去动态规模之外，服务还必须基于用户正在浏览的视频或者是地理位置来推测用户的喜好。比如说，某个页面可能会将一个独立的视频片段与本地的促销，视频系列的额外部分，甚至是相关视频联系起来。为了能让用户能在网站上停留更长的时间，他们建立了一个能基于详细元数据自动建立页面的软件引擎，这个引擎可以根据用户当下兴趣推荐额外的内容。鉴于用于兴趣的随时改变，数据的类型非常广泛——类似graph-like，实际上做的是大量的join。这样做有利于减少类似视频的大体积文件副本数，比如数据存储中一个独立的记录是Southpark片段“CartmangetsanAnalProbe”，这个片段可能也会出现在德语的网站上。虽然视频是一样的，但是英语用户搜索的可能就是另一个不同的词语。元数据的副本转换成搜索结果，并指向相同的视频。因此在美国用户搜索真实标题的情况下，德国浏览者可能会使用转译的标题——德国网站上的“CartmanunddieAnalsonde”。这些元数据覆盖了其它记录或者是对象，同时还可以根据使用环境来改变内容，通过不同的规则集来限制不同地理位置或者是设备请求的内容。2.Viacom的实现方法尽管许多机构通过使用ORM及传统关系型数据库来解决这个问题，Viacom却使用了一个迥然不同的方法。本质上，他们完全承担不了对数据库的直接访问。首先，他们处理的大部分都是流数据，他们偏向于使用Akamai从地理上来分配内容。其次，基于页面的复杂性可能会取上万个对象。取如此多的数据显然会影响到性能，因此JSON在1个数据服务中投入了使用。当然，这些JSON对象的缓存将直接影响到网站性能。同时，当内容或者是内容之间的关系发生改变时，缓存还需要动态的进行更新。Viacom依靠对象基元和超类解决这个问题，继续以SouthPark为例：一个私有的“episode”类包含了所有该片段相关信息，一个“superobject”将有助于发现实际的视频对象。超类这个思想确实非常有益于建设低延迟页面的自动建设，这些超类可以帮助到基元对象到缓存的映射及保存。3.Viacom为什么要使用Redis每当Viacom上传一个视频片段，系统将建立一个私有的对象，并于1个超类关联。每一次修改，他们都需要重估私有对象的每个改变，并更新所有复合对象。同时，系统还需要无效Akamail中的URL请求。系统现有架构的组合及更敏捷的管理方法需求将Viacom推向了Redis。基于Viacom主要基于PHP，所以这个解决方案必须支持PHP。他们首先选择了memcached做对象存储，但是它并不能很好的支持hashmap；同时他们还需要一个更有效的进行无效步骤的重估，即更好的理解内容的依赖性。本质上说，他们需要时刻跟进无效步骤中的依赖性改变。因此他们选择了Redis及Predis的组合来解决这个问题。他们团队使用Redis给southparkstudios.com和thedailyshow.com两个网站建设依赖性图，在取得了很大的成功后他们开始着眼Redis其它适合场景。Redis的其它使用场景显而易见，如果有人使用Redis来建设依赖性图，那么使用它来做对象处理也是说得通的。同样，这也成了架构团队为Redis选择的第二使用场景。Redis的复制及持久化特性同时也征服了Viacom的运营团队，因此在几个开发周期后，Redis成为他们网站的主要数据及依赖性储存。后两个用例则是行为追踪及浏览计数的缓冲，改变后的架构是Redis每几分钟向MySQL中储存一次，而浏览计数则通过Redis进行存储及计数。同时Redis还被用来做人气的计算，一个基于访问数及访问时间的得分系统——如果某个视频最近被访问的次数越多，它的人气就越高。在如此多内容上每隔10-15分钟做一次计算绝对不是类似MySQL这样传统关系型数据库的强项，Viacom使用Redis的理由也非常简单——在1个存储浏览信息的Redis实例上运行Lua批处理作业，计算出所有的得分表。信息被拷贝到另一个Redis实例上，用以支持相关的产品查询。同时还在MySQL上做了另一个备份，用以以后的分析，这种组合会将这个过程耗费的时间降低60倍。Viacom还使用Redis存储一步作业信息，这些信息被插入一个列表中，工作人员则使用BLPOP命令行在队列中抓取顶端的任务。同时zsets被用于从众多社交网络（比如Twitter及Tumblr）上综合内容，Viacom通过Brightcove视频播放器来同步多个内容管理系统。横跨这些用例，几乎所有的Redis命令都被使用——sets、lists、zlists、hashmaps、scripts、counters等。同时，Redis也成为Viacom可扩展架构中不可或缺的一环。
中国互联网举报中心