Mikel

[转载]网架构学习笔记 – #知了 – 博客园. 最近在网上溜达时，看到优酷网架构学习笔记，感觉很不错，转过来与大家分享。 记得以前给大家介绍过视频网站龙头老大YouTube的技术架构，相信大家看了都会有不少的感触，互联网就是这么一 个神奇的东西。今天我突然想到，优酷网在国内也算是视频网站的老大了，不知道他的架构相对于YouTube是怎么样的，于是带着这个好奇心去网上找了优酷 网架构的各方面资料，虽然谈得没有YouTube那么详细，但多少还是挖掘了一点，现在总结一下，希望对喜欢架构的朋友有所帮助。 一、网站基本数据概览 据2010年统计，优酷网日均独立访问人数（uv)达到了8900万，日均访问量（pv）更是达到了17亿，优酷凭借这一数据成为google榜单中国内视频网站排名最高的厂商。 硬件方面，优酷网引进的戴尔服务器主要以 PowerEdge 1950与PowerEdge 860为主，存储阵列以戴尔MD1000为主，2007的数据表明，优酷网已有1000多台服务器遍布在全国各大省市，现在应该更多了吧。 二、网站前端框架 从一开始，优酷网就自建了一套CMS来解决前端的页面显示，各个模块之间分离得比较恰当，前端可扩展性很好，UI的分离，让开发与维护变得十分简单和灵活，下图是优酷前端的模块调用关系： 这样，就根据module、method及params来确定调用相对独立的模块，显得非常简洁。下面附一张优酷的前端局部架构图： 三、数据库架构 应该说优酷的数据库架构也是经历了许多波折，从一开始的单台MySQL服务器（Just Running）到简单的MySQL主从复制、SSD优化、垂直分库、水平sharding分库，这一系列过程只有经历过才会有更深的体会吧，就像 MySpace的架构经历一样，架构也是一步步慢慢成长和成熟的。 1、简单的MySQL主从复制: MySQL的主从复制解决了数据库的读写分离，并很好的提升了读的性能，其原来图如下： 其主从复制的过程如下图所示： 但是，主从复制也带来其他一系列性能瓶颈问题： 写入无法扩展 写入无法缓存 复制延时 锁表率上升 表变大，缓存率下降 那问题产生总得解决的，这就产生下面的优化方案，一起来看看。 2、MySQL垂直分区 如果把业务切割得足够独立，那把不同业务的数据放到不同的数据库服务器将是一个不错的方案，而且万一其中一个业务崩溃了也不会影响其他业务的正常进行，并且也起到了负载分流的作用，大大提升了数据库的吞吐能力。经过垂直分区后的数据库架构图如下： 然而，尽管业务之间已经足够独立了，但是有些业务之间或多或少总会有点联系，如用户，基本上都会和每个业务相关联，况且这种分区方式，也不能解决单张表数据量暴涨的问题，因此为何不试试水平sharding呢？ 3、MySQL水平分片（Sharding） 这是一个非常好的思路，将用户按一定规则（按id哈希）分组，并把该组用户的数据存储到一个数据库分片中，即一个sharding，这样随着用户数量的增加，只要简单地配置一台服务器即可，原理图如下： 如何来确定某个用户所在的shard呢，可以建一张用户和shard对应的数据表，每次请求先从这张表找用户的shard id，再从对应shard中查询相关数据，如下图所示： 但是，优酷是如何解决跨shard的查询呢，这个是个难点，据介绍优酷是尽量不跨shard查询，实在不行通过多维分片索引、分布式搜索引擎，下策是分布式数据库查询（这个非常麻烦而且耗性能） 四、缓存策略 貌似大的系统都对“缓存”情有独钟，从http缓存到memcached内存数据缓存，但优酷表示没有用内存缓存，理由如下： 避免内存拷贝，避免内存锁 如接到老大哥通知要把某个视频撤下来，如果在缓存里是比较麻烦的 而且Squid 的 write() 用户进程空间有消耗，Lighttpd 1.5 的 AIO(异步I/O) 读取文件到用户内存导致效率也比较低下。 但为何我们访问优酷会如此流畅，与土豆相比优酷的视频加载速度略胜一筹？这个要归功于优酷建立的比较完善的内容分发 网络（CDN），它通过多种方式保证分布在全国各地的用户进行就近访问——用户点击视频请求后，优酷网将根据用户所处地区位置，将离用户最近、服务状况最 好的视频服务器地址传送给用户，从而保证用户可以得到快速的视频体验。这就是CDN带来的优势，就近访问，有关CDN的更多内容，请大家Google一 [...]

[转载]短链接算法收集与分析 – Cocowool – 博客园. 短链接就不说了，大家已经都清楚了，如下所示就是短链接： 新浪微博     http://t.cn/SVpONM 腾讯微博     http://url.cn/302yor Yun.io         http://d.yun.io/PNri2v 短链接的好处：1、内容需要；2、用户友好；3、便于管理。 如何实现呢，大概有三个步骤： 1、定义一个URL映射算法，可以将长的URL映射成短字符串； 2、使用一个存储（数据库？NoSQL？）来存储完成的映射； 3、实现自己的URL映射算法； 一般来说，第三步是我们比较头疼的，如何将一个长的URL字符串，映射成一个较短的字符串呢。我总结了三种办法： 普通实现 我想以前大家学习过十进制和二进制的互相转换，或者十进制和十六进制的互相转换，那么为了更短，我们可以使用62进制，对于一个数字ID进行转码，转换成一个短字符串。 这种做法的缺点是没有办法保证所有链接都是固定的位数的长度，而且在高并发的情况下，如何保证能够快速分发是个问题。 具体实现方法： /** * 利用62进制对数字ID进行短链接编码，缺点不能保证每个短链接是固定长度 * * @author  wanshiqiang<wangshiqiang@360.cn> * @param integer $integer * @param string $base */ private function getShortenedURLFromID ($integer, $base = ALLOWED_CHARS) { $length = strlen($base); while($integer > $length – 1) { [...]

[转载]B2C电子商务系统研发——商品SKU分析和设计（一） – 颜超敏 – 博客园. 一、SKU及相关概念定义 在设计商品SKU之前，首先让我们熟悉一下SKU和相关的一些概念。 # 什么是SKU： SKU=Stock Keeping Unit(库存量单位) 同一型号的商品，或者说是同一个产品项目（商品条形码是针对企业的产品 项目来进行定义的），因为产品与产品之间有某些属性不同，用以区别开这些 不同商品的属性即商品变异属性，又称作SKU属性，因为它决定了SKU 的绝对数量。 # 参考说明 百度上有一篇文章也有阐述，可以做关联阅读，我就不重复贴上了。 http://www.cnblogs.com/winstonyan/admin/EditPosts.aspx # 什么是SKU属性和选项 比如某件衣服有多种颜色、多种尺码，这些属性会直接关联价格和库存的， 系统会根据该商品关联的SKU属性的某个组合生成SKU。 比如某个款式的衬衫，有XL/L/XXL三种大小，有红黄蓝三种颜色。 对应这里例子，尺码和颜色都是是SKU属性。 对应尺码的XL/L/XXL等，都是SKU属性选项。 【注】上述的属性不一定在任何时候都是SKU属性，看实际的商品情况和设置。 比如对于尺码，某种商品是均码的。那么就不需要创建尺码这个SKU属性了， 而是设置为普通属性，仅作为显示用。 # 什么是商品SKU 商品SKU实际上就是SKU，为了避免误解和SKU属性混淆，我用商品SKU来命名， 表示从属于商品的、实际销售和存储的子实体。 一个商品SKU，表示该商品关联的若干SKU属性的的属性值的某个组合所形成的 子实体。 如对应上面的例子，其中的一种组合 XL + 红色 就会形成一个商品SKU。然后， 我们可以在该实体上管理价格、库存、专门的图片等信息。 # 什么是商品变异 英文名：Product Variants 商品变异其实就是商品SKU，只不过在某些技术文章中这样定义了。即以“变异” 来表达商品SKU的生成。 # 属性集 B2C电子商务系统研发——商品SKU分析和设计（一） Attribute Set，用于管理各类扩展属性的集合，其中SKU属性也是在管理范畴之内。 商品通过关联属性集而获得该属性集设置好的SKU属性，然后才可以根据这些SKU属性 生成商品SKU。 [...]

[转载]B2C电子商务系统研发——商品模块E-R图建模 – 颜超敏 – 博客园. 【说明】：这只是我提出的一种建模思路，电子商务的业务比较复杂，而且各个网站和系统会有其特定的需求， 这个模型虽然具备一定的通用性，但不能保证适用所有的业务。各位读者可以根据自己项目的需要来做调整。 商品 模块的核心实体之一。承担和内部、外部的关联。该表内设计基础属性和冗余信息。 前台商品详细页面，已本实体的记录作为单元，一条记录一个详细页面。 商品SKU 模块的另一个核心实体，从属于商品。每一个商品SKU是商品关联的规格的一种组合。 比如 [颜色SKU-红色] + [尺码SKU-42码] 形成一种组和。这个组合构成一个商品SKU。 价格、库存和关联购物车、订单等，都通过此实体完成。 商品描述 和商品是一对一关系，将只会在商品详细页面使用的SEO、描述等相关字段分离出来， 对提高商品列表的检索效率会有帮助。 商品媒体 通过媒体类型来区分图片、视频和文档等。 属性扩展模块 上面粉红色框住的部分是属性扩展模块，通过各类关联为商品模块实现SKU、评论项、查询属性和普通描述性 属性的扩展。从设计上考虑，属性扩展模块并不从属商品模块，它可以为其它的实体（如分类、订单、客户） 提供属性扩展服务。当然SKU属性则是商品独有的。 商品库存 这块是可选的设计，需要专设一章来分析，而对于有紧迫进度要求的项目，可以先直接在商品SKU实体中设计 一个“库存数量”字段，留待以后扩展也可以。 /*728*90，创建于2011-1-13*/ var cpro_id = ‘u350373′;

[转载]B2C电子商务系统研发——商品数据模型设计 – 元亨利贞 – 博客园. 基础属性 指设计在商品表的一些基础字段。 其中可选的设计点有： # 副名称：由于商品名称经常要加上一些促销信息，如本商品参与什么活动之类。但经常改动主名称 容易导致出错，所以增加此字段来专门管理促销信息。显示时连接到主名称后即可。 # 产品描述：产品描述建议另设计一表存放，对提高产品搜索、产品列表显示有帮助。 # 状态：常见的状态有草稿、未发布、发布、下架等，如果是逻辑删除的，还有“已删除”状态。 价格 如果系统支持产品SKU，那么实际价格是在产品SKU实体中管理的。 促销价格不在这里管理，在营销管理模块统一管理。 SEO相关 集中管理各类SEO相关的信息。 商品媒体 #主图：由于显示频繁，会直接设计在产品表中（或是冗余）。 #多图（即附图）：开发中会提供多种查看方式。 扩展属性 这是设计最困难的部分，也是商品是否可以灵活扩展的关键。 库存 库存这里是常见的开发迭代点。 在研发早期，一般这里直接设计成支持零库存和单一数值库存。 在其它功能完成后，才会对这里做扩展，开发内嵌的库存子模块或者整合外部系统。 外部关联 商品的外部关联非常的多，这里列出了大部分，但随着系统的扩展，肯定会有新的外部关联实体。 所以商品模块的开发，需要提供大量的外部接口或者Tag封装（如商品选取器等。） /*728*90，创建于2011-1-13*/ var cpro_id = ‘u350373′;