CSDN上的文章，记录下来，没事的时候关注下文章中提到的技术。

Pinterest一直保持着指数增长，每一个半月都会翻一翻。在两年内，他们实现了从0到数百亿的月PV；从开始的两个创始人加一个工程师增长到现在超过40个工程师，从一个小型的MySQL服务器增长到180个Web Enigne、240个API Enigne、88个MySQL DB（cc2.8xlarge，每个DB都会配置一个奴节点）、110个Redis Instance以及200个Mmecache Instance。

在一个名为 《Scaling Pinterest》 的主题演讲上，Pinterest的Yashwanth Nelapati和 Marty Weiner为我们讲述了这个戏剧性的过程。当然扩展到当下规模，Pinterest在众多选择中不可避免的走了许多的弯路，而Todd Hoff认为其中最宝贵的经验该归结于以下两点：

1. 如果你的架构应对增长所带来的问题时，只需要简单的投入更多的主机，那么你的架构含金量十足。
2. 当你把事物用至极限时，这些技术都会以各自不同的方式发生故障，这导致他们对工具的选择有着特殊的偏好：成熟、简单、优秀、知名、被更多的用户喜爱、更好的支持、稳定且杰出的表现、通常情况下无故障以及免费。使用这些标准，他们选择了MySQL、Solr、Memcache、Redis、Cassandra，同时还抛弃了MongoDB。

同样这两个点是有关联的，符合第二个原则的工具就可以通过投入更多的主机进行扩展。即使负载的增加，项目也不会出现很多故障。即使真的出现难以解决的问题，至少有一个社区去寻找问题解决的方案。一旦你选择过于复杂和挑剔的工具，在扩展的道路上将充满荆棘。

需要注意的是所有他们选择的工具都依靠增加分片来进行扩展，而非通过集群。讲话中还阐述了为什么分片优于集群以及如何进行分片，这些想法可能是之前你闻所未闻的。

下面就看一下Pinterest扩展的阶段性时间轴：

项目背景

• Pins是由其它零零碎碎信息集合成的图片，显示了对客户重要的信息，并且链接到它所在的位置。
• Pinterest是一个社交网络，你可以follow（关注）其它人以及board。
• 数据库：Pinterest的用户拥有board，而每个board都包含pin；follow及repin人际关系、验证信息。

1. 2010年3月发布——寻找真我的时代

在那时候，你甚至不知道需要建立一个什么样的产品。你有想法，所以你快速的迭代以及演变。而最终你将得到一些很小的MySQL查询，而这些查询在现实生活中你从未进行过。

Pinterest初期阶段的一些数字：

• 2个创始人
• 1个工程师
• Rackspace
• 1个小的网络引擎
• 1个小的MySQL数据库
• 2011年11月

仍然是小规模，产品通过用户反馈进行演变后的数字是：

• Amazon EC2 + S3 + CloudFront
• 1 NGinX, 4 Web Engines (用于冗余，不全是负载)
• 1 MySQL DB + 1 Read Slave (用于主节点故障情况)
• 1 Task Queue + 2 Task Processors
• 1 MongoDB (用于计数)
• 2 Engineers

2. 贯穿2011年——实验的时代

迈上疯狂增长的脚步，基本上每1个半月翻一翻。

• 当你增长的如此之快，每一天每一星期你可能都需要打破或者抛弃一些东西。
• 在这个时候，他们阅读大量的论文，这些论文都阐述着只需要添加一台主机问题就会得以解决。他们着手添加许多技术，随后又不得不放弃。
• 于是出现了一些很奇怪的结果 ：

• Amazon EC2 + S3 + CloudFront
• 2NGinX, 16 Web Engines + 2 API Engines
• 5 Functionally Sharged MySQL DB + 9 read slaves
• 4 Cassandra Nodes
• 15 Membase Nodes (3 separate clusters)
• 8 Memcache Nodes
• 10 Redis Nodes
• 3 Task Routers + 4 Task Processors
• 4 Elastic Search Nodes
• 3 Mongo Clusters
• 3个工程师

• 5个主数据库技术，只为了独立其中的数据。
• 增长太快以至于MySQL疲于奔命，所有其它的技术也达到了极限。
• 当你把事物用至极限时，这些技术都会以各自不同的方式出错。
• 开始抛弃一些技术，并且自我反省究竟需要些什么，基本上重做了所有的架构。

3. 2012年2月——成熟的时代

• 在重做了所有的架构后，系统呈现了如下状态

• Amazon EC2 + S3 + Akamai, ELB
• 90 Web Engines + 50 API Engines
• 66 MySQL DBs (m1.xlarge) +，每个数据库都配备了奴节点
• 59 Redis Instances
• 51 Memcache Instances
• 1 Redis Task Manager + 25 Task Processors
• Sharded Solr
• 6个工程师

• 现在采用的技术是被分片的MySQL、Redis、Memcache和Solr，有点在于这些技术都很简单很成熟。
• 网络传输增长仍然保持着以往的速度，而iPhone传输开始走高。

4. 2012年10月12日 —— 收获的季节

大约是1月份的4倍

• 现在的数据是：

• Amazon EC2 + S3 + Edge Cast,Akamai, Level 3
• 180 Web Engines + 240 API Engines
• 88 MySQL DBs (cc2.8xlarge) ，同样每个数据库都有一个奴节点
• 110 Redis Instances
• 200 Memcache Instances
• 4 Redis Task Manager + 80 Task Processors
• Sharded Solr
• 40个工程师（仍在增长）

• 需要注意的是，如今的架构已趋近完美，应对增长只需要投入更多的主机。
• 当下已开始转移至SSD

---

 

下面一览该演讲中的干货，决策的制定：

为什么会选择EC2和S3

1. 相当好的可靠性，即使数据中心发生故障。多租户会增加风险，但是也不是太坏。
2. 良好的报告和支持。它们（EC2和S3）有着良好的架构，并且知道问题所在。
3. 完善的周边设施，特别是在你需要快速增长时。你可以从APP Engine处获得maged cache、负载均衡、MapReduce、数据库管理以及其它你不想自己动手编写的组件，这可以加速你应用程序的部署，而在你工程师空闲时，你可以着手编写你需要的一切。
4. 新的实例可以在几秒内就绪，这就是云的力量；特别是在只有两个工程师的初期，不需要去担心容量规划，更不需要花两个星期去建立自己的Memcache，你可以在数分钟内添加10个Memcached。
5. 缺点：有限的选择。直到最近，才可以选择使用SSD，同时无法获得太大的内存配置。
6. 优点：你不需要给大量的主机进行不同的配置。

为什么会选择MySQL

1. 非常成熟。
2. 非常稳定。不会宕机，并且不会丢失数据。
3. 在招聘上具有优势，市场上有大把的人才。
4. 在请求呈直线上升时，仍能将相应时间控制在一定的范围内，有些数据库技术在面对请求的飙升时表现并不是很好。
5. 非常好的周边软件支持——XtraBackup、Innotop、Maatkit。
6. 可以从类似Percona这样的公司得到优秀的技术支持。
7. 开源（免费）——这一点非常重要，特别是在资金缺乏的初期

为什么使用Memcache

• 非常成熟。
• 非常简单。可以当成是一个socket哈希表
• 杰出稳定的表现
• 知名并为大量用户喜爱
• 永不崩溃
• 开源

为什么选择Redis

• 虽然还不够成熟，但是非常简单及优秀
• 提供了大量的数据结构类型
• 提供多种的选择进行持久化和备份：你可以备份而非持久化，选择备份的话你还可以选择多久备份一次；同样你还可以选择使用什么方式进行持久化，比如MySQL等。

• Home feed被储存在Redis上，每3个小时保存一次；然而并不是3个小时持久化一次，只是简单的每3个小时备份一次。
• 如果你存储数据的主机发生故障，丢失的也只是备份周期内的数据。虽然不是完全可靠，但是非常简单。避免了复杂的持久化及复制，这样的架构简单且便宜。

• 知名并为大量用户喜爱
• 稳定且杰出的表现
• 很少出故障。有一些专有的故障模型，你需要学会解决。这也是成熟的优势，只需要学习就可以解决。
• 开源

Solr

1. 只需要几分钟的安装时间，就可以投入使用
2. 不能扩展到多于一台的机器上（最新版本并非如此）
3. 尝试弹性搜索，但是以Pinterest的规模来说，可能会因为零碎文件和查询太多而产生问题。
4. 选择使用Websolr，但是Pinterest拥有搜索团队，将来可能会开发自己的版本。

集群vs.分片

• 在迅速扩展的过程中，Pinterest认识到每次负载的增加，都需要均匀的传播他们的数据。
• 针对问题先确定解决方案的范围，他们选择的范围是集群和分片之间的一系列解决方案。

集群——所有的操作都是通过自动化

• 比如：Cassandra、MemBase、HBase
• 结论：没有安全感，将来可能会比较成熟，但是当下这个解决方案中还存在太多的复杂性和故障点。
• 特性：

• 数据自动分布
• 节点间转移数据
• 需要平衡分配
• 节点间的相互通信，需要做很多措施用于防止干扰、无效传递及协商。

• 优点：

• 自动扩展你的数据存储，最起码论文中是这么说的。
• 便于安装
• 数据上的空间分布及机房共置。你可以在不同区域建立数据中心，数据库会帮你打理好一切。
• 高有效性
• 负载平衡
• 不存在单点故障

• 缺点：

• 仍然不成熟。
• 本质上说还很复杂。一大堆的节点必须对称协议，这一点非常难以解决。
• 缺少社区支持。社区的讨论因为产品方向的不同而不能统一，而在每个正营中也缺乏强有力的支持。
• 缺乏领域内资深工程师，可能大多数的工程师都还未使用过Cassandra。
• 困难、没有安全感的机制更新。这可能是因为这些技术都使用API并且只在自己的领域内通行，这导致了复杂的升级路径。
• 集群管理算法本身就用于处理SPOF（单点故障），如果存在漏洞的话可能就会影响到每个节点。
• 集群管理器代码非常复杂，并且需要在所有节点上重复，这就可能存在以下的故障模式：

• 数据平衡失控。当给集群中添加新的主机时，可能因为数据的拷贝而导致集群性能下降。那么你该做什么？这里不存在去发现问题所在的工具。没有社区可以用来求助，同样你也被困住了，这也是Pinterest回到MySQL的原因。
• 跨节点的数据损坏。如果这里存在一个漏洞，这个漏洞可能会影响节点间的日志系统和压缩等其它组件？你的读延时增加，所有的数据都会陷入麻烦以及丢失。
• 错误负载平衡很难被修复，这个现象十分普遍。如果你有10个节点，并且你注意到所有的负载都被堆积到一个节点上。虽然可以手动处理，但是之后系统还会将负载都加之一个节点之上。
• 数据所有权问题，主次节点转换时的数据丢失。集群方案是非常智能的，它们会在特定的情况下完成节点权利的转换，而主次节点切换的过程中可能会导致数据的部分丢失，而丢失部分数据可能比丢失全部还糟糕，因为你不可能知道你究竟丢失了哪一部分。

分片——所有事情都是手动的

• 结论：它是获胜者。Todd Hoff还认为他们的分片架构可能与Flickr架构类似。
• 特性：

• 分片可以让你摆脱集群方案中所有不想要的特性。
• 数据需要手动的分配。
• 数据不会移动。Pinterest永远都不会在节点间移动，尽管有些人这么做，这让他们在一定范围内站的更高。
• 通过分割数据的方式分配负载。
• 节点并没有互相通信，使用一些主节点控制程序的运行。

• 优点：

• 可以分割你的数据库以提高性能。
• 空间分布及放置数据
• 高有效性
• 负载平衡
• 放置数据的算法非常简单。主要原因是，用于处理单点故障的代码只有区区的半页，而不是一个复杂的集群管理器。并且经过短暂的测试就知道它是否能够正常工作。
• ID生成非常简单

• 缺点：

• 不可以执行大多数的join。
• 失去所有事务的能力。在一个数据库上的插入可能会成功，而在另一个上会失败。
• 许多约束必须放到应用程序层。
• 模式的转变需要从长计议。
• 报告需要在所有分片上执行查询，然后需要手动的进行聚合。
• Join在应用程序层执行。
• 应用程序必须容忍以上所有问题。

什么时候进行分片

1. 如果你的项目拥有PB级的数据，那么你需要立刻对其进行分片。
2. Pin表格拥有百万行索引，索引大小已经溢出内存并被存入了磁盘。
3. Pinterest使用了最大的表格，并将它们（这些索引）放入自己的数据库。
4. 然后果断的超过了单数据库容量。
5. 接着Pinterest必须进行分片。

分片的过渡

• 过渡从一个特性的冻结开始。
• 确认分片该达到什么样的效果——希望尽少的执行查询以及最少数量的数据库去呈现一个页面。
• 剔除所有的MySQL join，将要做join的表格加载到一个单独的分片去做查询。
• 添加大量的缓存，基本上每个查询都需要被缓存。
• 这个步骤看起来像：

• 1 DB + Foreign Keys + Joins
• 1 DB + Denormalized + Cache
• 1 DB + Read Slaves + Cache
• Several functionally sharded DBs+Read Slaves+Cache
• ID sharded DBs + Backup slaves + cache

• 早期的只读奴节点一直都存在问题，因为存在slave lag。读任务分配给了奴节点，然而主节点并没有做任何的备份记录，这样就像一条记录丢失。之后Pinterest使用缓存解决了这个问题。
• Pinterest拥有后台脚本，数据库使用它来做备份。检查完整性约束、引用。
• 用户表并不进行分片。Pinterest只是使用了一个大型的数据库，并在电子邮件和用户名上做了相关的一致性约束。如果插入重复用户，会返回失败。然后他们对分片的数据库做大量的写操作。

如何进行分片

• 可以参考Cassandra的ring模型、Membase以及Twitter的Gizzard。
• 坚信：节点间数据传输的越少，你的架构越稳定。
• Cassandra存在数据平衡和所有权问题，因为节点们不知道哪个节点保存了另一部分数据。Pinterest认为应用程序需要决定数据该分配到哪个节点，那么将永远不会存在问题。
• 预计5年内的增长，并且对其进行预分片思考。
• 初期可以建立一些虚拟分片。8个物理服务器，每个512DB。所有的数据库都装满表格。
• 为了高有效性，他们一直都运行着多主节点冗余模式。每个主节点都会分配给一个不同的可用性区域。在故障时，该主节点上的任务会分配给其它的主节点，并且重新部署一个主节点用以代替。
• 当数据库上的负载加重时：

• 先着眼节点的任务交付速度，可以清楚是否有问题发生，比如：新特性，缓存等带来的问题。
• 如果属于单纯的负载增加，Pinterest会分割数据库，并告诉应用程序该在何处寻找新的节点。
• 在分割数据库之前，Pinterest会给这些主节点加入一些奴节点。然后置换应用程序代码以匹配新的数据库，在过渡的几分钟之内，数据会同时写入到新旧节点，过渡结束后将切断节点之间的通道。

ID结构

• 一共64位

• 分片ID：16位
• Type：10位—— Board、User或者其它对象类型
• 本地ID——余下的位数用于表中ID，使用MySQL自动递增。

• Twitter使用一个映射表来为物理主机映射ID，这将需要备份；鉴于Pinterest使用AWS和MySQL查询，这个过程大约需要3毫秒。Pinterest并没有让这个额外的中间层参与工作，而是将位置信息构建在ID里。
• 用户被随机分配在分片中间。
• 每个用户的所有数据（pin、board等）都存放在同一个分片中，这将带来巨大的好处，避免了跨分片的查询可以显著的增加查询速度。
• 每个board都与用户并列，这样board可以通过一个数据库处理。
• 分片ID足够65536个分片使用，但是开始Pinterest只使用了4096个，这允许他们轻易的进行横向扩展。一旦用户数据库被填满，他们只需要增加额外的分片，然后让新用户写入新的分片就可以了。

查找

• 如果存在50个查找，举个例子，他们将ID分割且并行的运行查询，那么延时将达到最高。
• 每个应用程序都有一个配置文件，它将给物理主机映射一个分片范围。

• “sharddb001a”: : (1, 512)
• “sharddb001b”: : (513, 1024)——主要备份主节点

 

• 如果你想查找一个ID坐落在sharddb003a上的用户：

• 将ID进行分解
• 在分片映射中执行查找
• 连接分片，在数据库中搜寻类型。并使用本地ID去寻找这个用户，然后返回序列化数据。

对象和映射

• 所有数据都是对象（pin、board、user、comment）或者映射（用户由baord，pin有like）。
• 针对对象，每个本地ID都映射成MySQL Blob。开始时Blob使用的是JSON格式，之后会给转换成序列化的Thrift。
• 对于映射来说，这里有一个映射表。你可以为用户读取board，ID包含了是时间戳，这样就可以体现事件的顺序。

• 同样还存在反向映射，多表对多表，用于查询有哪些用户喜欢某个pin这样的操作。
• 模式的命名方案是：noun_verb_noun: user_likes_pins, pins_like_user。

• 只能使用主键或者是索引查找（没有join）。
• 数据不会向集群中那样跨数据的移动，举个例子：如果某个用户坐落在20分片上，所有他数据都会并列存储，永远不会移动。64位ID包含了分片ID，所以它不可能被移动。你可以移动物理数据到另一个数据库，但是它仍然与相同分片关联。
• 所有的表都存放在分片上，没有特殊的分片，当然用于检测用户名冲突的巨型表除外。
• 不需要改变模式，一个新的索引需要一个新的表。

• 因为键对应的值是blob，所以你不需要破坏模式就可以添加字段。因为blob有不同的版本，所以应用程序将检测它的版本号并且将新记录转换成相应的格式，然后写入。所有的数据不需要立刻的做格式改变，可以在读的时候进行更新。
• 巨大的胜利，因为改变表格需要在上面加几个小时甚至是几天的锁。如果你需要一个新的索引，你只需要建立一张新的表格，并填入内容；在不需要的时候，丢弃就好。

呈现一个用户文件界面

1. 从URL中取得用户名，然后到单独的巨型数据库中查询用户的ID。
2. 获取用户ID，并进行拆分
3. 选择分片，并进入
4. SELECT body from users WHERE id = <local_user_id>
5. SELECT board_id FROM user_has_boards WHERE user_id=<user_id>
6. SELECT body FROM boards WHERE id IN (<boards_ids>)
7. SELECT pin_id FROM board_has_pins WHERE board_id=<board_id>
8. SELECT body FROM pins WHERE id IN (pin_ids)
9. 所有调用都在缓存中进行（Memcache或者Redis），所以在实践中并没有太多连接数据库的后端操作。

脚本相关

1. 当你过渡到一个分片架构，你拥有两个不同的基础设施——没有进行分片的旧系统和进行分片的新系统。脚本成为了新旧系统之间数据传输的桥梁。
2. 移动5亿的pin、16亿的follower行等。
3. 不要轻视项目中的这一部分，Pinterest原认为只需要2个月就可以完成数据的安置，然而他们足足花了4至5个月时间，别忘了期间他们还冻结了一项特性。
4. 应用程序必须同时对两个系统插入数据。
5. 一旦确认所有的数据都在新系统中就位，就可以适当的增加负载来测试新后端。
6. 建立一个脚本农场，雇佣更多的工程师去加速任务的完成。让他们做这些表格的转移工作。
7. 设计一个Pyres副本，一个到GitHub Resque队列的Python的接口，这个队列建立在Redis之上。支持优先级和重试，使用Pyres取代Celery和RabbitMQ更是让他们受益良多。
8. 处理中会产生大量的错误，用户可能会发现类似丢失board的错误；必须重复的运行任务，以保证在数据的处理过程中不会出现暂时性的错误。

开发相关

• 开始尝试只给开发者开放系统的一部分——他们每个人都拥有自己的MySQL服务器等，但是事情改变的太快，以至于这个模式根本无法实行。
• 转变成Facebook模式，每个人都可以访问所有东西，所以不得不非常小心。

未来的方向

• 基于服务的架构

• 当他们发现大量的数据库负载，他们开始布置大量的应用程序服务器和一些其它的服务器，所有这些服务器都连接至MySQL和Memcache。这意味着在Memcache上将存在3万的连接，这些连接将占用几个G的内存，同时还会产生大量的Memcache守护进程。
• 为了解决这个问题，将这些工作转移到了一个服务架构。比如：使用一个follower服务，这个服务将专注处理follower查询。这将接下30台左右的主机去连接数据库和缓存，从而减少了连接的数量。
• 对功能进行隔离，各司其职。让一个服务的开发者不能访问其它的服务，从而杜绝安全隐患。

 

学到的知识

1. 为了应对未来的问题，让其保持简单。
2. 让其变的有趣。只要应用程序还在使用，就会有很多的工程师加入，过于复杂的系统将会让工作失去乐趣。让架构保持简单就是大的胜利，新的工程师从入职的第一周起就可以对项目有所贡献。
3. 当你把事物用至极限时，这些技术都会以各自不同的方式发生故障。
4. 如果你的架构应对增长所带来的问题时，只需要简单的投入更多的主机，那么你的架构含金量十足。
5. 集群管理算法本身就用于处理SPOF，如果存在漏洞的话可能就会影响到每个节点。
6. 为了快速的增长，你需要为每次负载增加的数据进行均匀分配。
7. 在节点间传输的数据越少，你的架构越稳定。这也是他们弃集群而选择分片的原因。
8. 一个面向服务的架构规则。拆分功能，可以帮助减少连接、组织团队、组织支持以及提升安全性。
9. 搞明白自己究竟需要什么。为了匹配愿景，不要怕丢弃某些技术，甚至是整个系统的重构。
10. 不要害怕丢失一点数据。将用户数据放入内存，定期的进行持久化。失去的只是几个小时的数据，但是换来的却是更简单、更强健的系统！

原文链接： Scaling Pinterest – From 0 To 10s Of Billions Of Page Views A Month In Two Years （编译/仲浩 审校/王旭东）

在我们交易时，特别是用的外盘是，经常会看到我们的系统时间与平台上的时间不一样，比如，我现在做的tmg盘子，我的系统时间是晚上8点整，而tmg的mt4平台上的时间却是早上8点，我使用的mt5平台上的时间显示的是下午3点，这就说明这台mt4的服务器是在美国，而mt5的服务器在俄罗斯。

还有一种情况就是我看到历史数据里有一段强烈的波动，然后平台上的时间与当时发生的新闻时间不符，也基本上是这种情况。

下面我来解释下具体原因。

UTC与GMT时间

整个地球分为二十四时区，每个时区都有自己的本地时间。在国际上，为了统一起见，我们使用一个统一的时间，称为通用协调时(UTC, Universal Time Coordinated)。UTC与格林尼治平均时(GMT, Greenwich Mean Time)几乎一样，都与英国伦敦的本地时相同。

看我的标题写的是：MT4与MT5中的UTC或GMT时间详解，我提到的是UTC或GMT，其实软件里显示的是哪个我并不知道也没去注意，因为其实这两种时间格式对我们来讲并没有什么大的区别，我们只需要知道的就是：它们都是指的格林尼治标准时间，只不过UTC的称呼更为正式一点。两者的区别在于前者是一个天文上的概念，而后者是基于一个原子钟。在UTC中，每一年或两年会有一个“闰秒”，而我们一般不理 会这个“闰秒”。

UTC与GMT时间表示

我们经常会看到UTC+8和GMT+8这样的时间显示。其实这都表示中国北京的时间，解释起来就是格林尼治平均时+8个小时，时区差东为正，西为负。我们中国处于东时区，也就是正数。

前面我们说的美国和俄罗斯两个国家的时区分别处于GMT-5和GMT+3时区的所以跟我们本地的时间有差别，比如莫斯科的GMT+3,中国的GMT+8，就是说，中国的时间比莫斯科的快5个小时（8-3）。但美国纽约所使用的GMT-5本来应该和中国GMT+8差13个小时，可为什么有的时候我们看到的却是差12个小时呢？这里就涉及到另一个问题了：夏令时。

夏令时与冬令时

夏令时比标准时快一个小时。例如，在夏令时的实施期间，标准时间的上午10点就成了夏令时的上午11点。
夏令时，又称“日光节约时制”或“夏时制”，是一种为节约能源而人为规定地方时间的制度，在这一制度实行期间所采用的统一时间称为“夏令时间”。一般在天亮早的夏季人为将时间提前一小时，可以使人早起早睡，减少照明量，以充分利用光照资源，从而节约照明用电。各个采纳夏令时的国家具体规定不同。目前全世界有近110个国家每年要实行夏令时。

冬令时是在冬天使用的标准时间。在使用日光节约时制的地区，夏天时钟拨快一小时，冬天再拨回来。这时采用的是标准时间，也就是冬令时。

总结

1.就是UTC与GMT时间基本一样，每个时区的当地时间都不一样

2.UTC + 时区差 ＝ 本地时间

3.MT4与MT5中所使用的时间都是其服务器所在地所使用的时间。

原文: http://www.trader007.net/gmt-time-format-details/

当你有两个svn仓库，一个库是您的产品代码，另外一个库是公共代码库。发布代码时，需要从两个库同时发布，可以通过svn external 的属性将公共库作为产品库的一个目录共同发布，并且只是一种引用关系。你需要设置客户端或者服务器svn属性，如果是客户端设置，只对客户端有效，如果设置服务器端，将对所有签入签出都有效。属性设置在父目录上（相对于存放外部仓库的目录），属性的值格式为： Directory RepositoryURL。
例如：

Property	Value
svn:externals	Framework https://svn.example.com/Framework/trunk/Framework

用TortoiseSVN设置的方法：

客服端
假设开发目录是project目录，你需要在libs目录下增加一个Framework目录（外部仓库）。那么右键点击libs目录（Framework的父目录），选择”TortoiseSVN”,”Properties”,点击”New”,从下拉菜单选择 “svn:externals”,在键值的框内，输入Framework https://svn.example.com/Framework/trunk/Framework     ，关闭对话框。然后，右键选择libs目录，svn update,这时候，svn将在libs目录下创建一个叫Framework的目录，并从外部仓库检入这些外部仓库的文件到你本地的工作目录。
服务器端
假设开发目录是project目录，你需要在libs目录下增加一个Framework目录（外部仓库）。那么右键点击libs目录（Framework的父目录），选择”TortoiseSVN”,”Repo-Browser”,在弹出框中选择libs目录选择”Show Properties”,点击”New”，输入”svn:externals”,在键值的框内，输入Framework https://svn.example.com/Framework/trunk/Framework     ，关闭对话框。

 

TeamCity for External Project:

http://confluence.jetbrains.com/display/TCD7/Subversion

SVN External (Link):

http://stackoverflow.com/questions/2184115/svn-release-branch-and-externals

博客园上看到的文章，记下来，了解下NB的系统用到的哪些技术。。说不定以后可以参考使用。。

原文作者: Fenng | 可以转载, 但必须以超链接形式标明文章原始出处和作者信息及版权声明
原文网址: http://www.dbanotes.net/arch/quora_tech.html

总结中。。。

 

 

参考资源：

谈谈对于企业级系统架构的理解

结合领域驱动设计的SOA分布式软件架构

UML建模系列文章总结

(UML, PS: 如果以建造房子比喻，那么学习UML的过程，就是学习如何从建筑工人成长为建筑师的过程。一个软件工程师不能简单地只是掌握堆砌砖瓦的技术，还应该有设计高楼大厦的能力。)

一个简单的实例程序来提一下使用.NET SDK 中的几个有用的工具来修改别人的代码逻辑。比如我有个程序，用户输入一个 ID，如果大于100 则改用户是合法的用户，否则就是非法的。程序比较简单，主要是 Demo
我希望修改一下输入任何 ID，都是合法用户。

using System; 

public class DemoCrack 
{ 
    public static void  Main() 
    { 
        System.Console.WriteLine("Enter your ID"); 
        string s=Console.ReadLine(); 
        int j=System.Int32.Parse(s); 
        if(IsValid(j)==true) 
            { 
                Console.WriteLine("You are valid User"); 
            } 
        else 
            { 
                Console.WriteLine("Invalid user"); 
            } 
    } 

    public static  bool IsValid(int i) 
    { 
        if(i>100) 
            { 
                return true; 
            } 
        else 
            { 
                return false; 
            } 
    } 
}

文件另存为 DemoCrack.cs

然后编译这个应用程序，为了让大家容易读懂 中间代码，我加入调试信息。
运行
> csc DemoCrack.cs /debug+

DemoCrack.exe 就编译好了。 而这个 Exe 一般就是我们通常拿到别人写的组件或者应用
运行这个exe

DemoCrack.exe

Enter your ID
12
Invalid user

Enter your ID
120
You are valid User

假设我们现在只有 DemoCrack.exe 这个文件，我希望用户输入任何ID 都是合法的用户，接下来就是我们使用三个工具的时候了：）

你可以使用reflector 看一下这个源代码，一看就知道如何去修改代码逻辑，希望把 IsInvalid 这个函数永远返回true 就可以了。

我们首先拿到中间代码：为了让大家读懂il，我把源代码作为注释放在il 种了

运行

> ildasm /source DemoCrack.exe /out:crack.il

crack.il 就是我们的中间代码了，hoho。 接下来我们对他做稍微的修改

文件中 关于IsInvalid 的大概逻辑是：

 .method public hidebysig static bool  IsValid(int32 i) cil managed
  {
    // Code size       25 (0x19)
    .maxstack  2
    .locals init ([0] bool CS$1$0000,
             [1] bool CS$4$0001)
//000019:  
//000020:     public static  bool IsValid(int i) 
//000021:     { 
    IL_0000:  nop
//000022:         if(i>100) 
    IL_0001:  ldarg.0
    IL_0002:  ldc.i4.s   100
    IL_0004:  cgt
    IL_0006:  ldc.i4.0
    IL_0007:  ceq
    IL_0009:  stloc.1
//000023:             { 
//000024:                 return true; 
//000025:             } 
//000026:         else 
//000027:             { 
//000028:                 return false; 
//000029:             } 
//000030:     } 
//000031: }
    IL_000a:  ldloc.1
    IL_000b:  brtrue.s   IL_0012

//000023:             { 
    IL_000d:  nop
//000024:                 return true; 
    IL_000e:  ldc.i4.1
    IL_000f:  stloc.0
    IL_0010:  br.s       IL_0017

//000025:             } 
//000026:         else 
//000027:             { 
    IL_0012:  nop
//000028:                 return false; 
    IL_0013:  ldc.i4.0
    IL_0014:  stloc.0
    IL_0015:  br.s       IL_0017

//000029:             } 
//000030:     } 
    IL_0017:  ldloc.0
    IL_0018:  ret
  } // end of method DemoCrack::IsValid

上面的IL代码有高级语言的注释，很容易看懂，也很容易修改，修改后的逻辑：

  .method public hidebysig static bool  IsValid(int32 i) cil managed
  {
    // Code size       25 (0x19)
    .maxstack  2
    .locals init ([0] bool CS$1$0000,
             [1] bool CS$4$0001)
//000019:  
//000020:     public static  bool IsValid(int i) 
//000021:     { 

//000024:                 return true; 
    IL_000e:  ldc.i4.1
    IL_000f:  stloc.0

    IL_0017:  ldloc.0
    IL_0018:  ret
  } // end of method DemoCrack::IsValid

然后保存一下这个文件。

接下来就是编译成exe
运行

> Ilasm crack.il

然后确认一下我们改的 il 没有问题
调用

> PEVerify Crack.exe

一切OK 的话，就大功告成了。

接下来运行 Crack.exe
Enter your ID
12
You are valid User

PS: 本文测试时是.NET 4.0，VS2010 Command prompt

原文地址：http://www.cnblogs.com/montaque/archive/2005/01/10/89464.html

介绍

这篇文章介绍了基本的IL汇编语言知识，你可以用它从底层来分析你的.NET代码（任何.NET平台下的高级语言写的）。从底层，我说的底层是你的高级语言在编译器中完成它工作的地方，用这些基本知识，你可以为.NET语言重新开发一个你自己的编译器。

目录

• IL汇编语言介绍
• 评估堆栈
• IL数据类型
• 变量声明
• 判断和条件语句
• 循环
• 定义方法
• 通过引用传递参数
• 创建命名空间和类
• 对象的作用域
• 创建和使用类对象
• 创建构造函数和属性
• 创建WinForms窗体
• 错误和调试
• 总结
• 结论

任何时候你在.NET中编译你的代码，不管你使用什么语言。它都会被转换成一种中间语言IL（Intermediate Language ），通常也被叫做微软中间语言MSIL（Microsoft Intermediate Language ）或通用中间语言CIL（Common Intermediate Language）。你可以把IL当作是JAVA中的“字节码”（译者注：也是一种中间语言，由JAVA虚拟机编译成的）。如果你对.NET是怎样处理不同数据类型以及怎样把我们写的代码转换成IL代码等等问题感兴趣，那么知道一些IL知识是非常有用的，包括你会知道．NET编译器产生的代码是什么。所以如果你知道IL，那么你可以检查编译器产生的代码是否正确，或者根据需要做一些修改（可能在大多数时候是不需要的），你可以更改IL代码去对程序做一些改动（一些在高级语言中不允许的）增加你代码的性能。这也可以帮助你从底层去分析你的代码。另外，如果你计划为．NET写一个编译器，那么你就必须了解IL。

IL本身是以二进制格式存储的，所以我们不可能阅读。但是和其它二进制代码有汇编语言一样，IL也有一种汇编语言叫作IL汇编语言（ＩＬＡｓｍ），IL汇编语言和其它汇编语言一样有许多指令。例如，两个数相加，有相加的指令，两个数相减，有相减的指令，等等。很显然．NET的运行时中的编译器（JIT）不能直接执行IL汇编语言，如果你用IL汇编语言编写了一些代码，那么首先你要把这些代码编译成IL代码，然后JIT才可以运行这些代码。

注意：请注意IL和IL汇编语言是两个不同的概念，当我们说到IL时，是指．ＮＥＴ编译器产生的二进制代码，而IL汇编语言不是二进制格式的。

IL汇编语言简介
现在我们开始我写这篇文章的主要目的，介绍IL汇编语言。IL汇编语言和其它汇编语言一样有一系列指令集。你可以在任何文本编辑器里面写IL汇编语言代码，像记事本等等然后用.NET平台自带的命令行编译器(ILAsm.exe)去编译它。对于使用高级语言的程序员来说，IL汇编语言是一种非常难以学习的语言，而对于使用C 或C++的程序员来说，可以很容易的接受它。学习IL汇编语言是很困难的工作，所以我们不要浪费时间，直入正题。在IL汇编语言中，我们要人工的做一切事情，包括数据进栈，内存管理等等。 你可以把IL汇编语言和汇编语言认为是一样的，但是汇编语言是在windos平台下执行的，而IL汇编语言是在.NET平台下执行的，另外还有一点就是IL汇编语言比汇编语言要简单一些，并且还有一些面向对象的特性。

。。。。。。。。。

更多参考：

http://www.cnblogs.com/xiaoxiangfeizi/archive/2011/08/08/2130768.html

http://www.codeproject.com/Articles/3778/Introduction-to-IL-Assembly-Language

http://stackoverflow.com/questions/9021677/loading-xaml-at-runtime-using-the-mvvm-pattern-in-wpf

文章的标题真的很难定义，想了半天，这个标题还比较能表达本篇文章的意义。

在.net 3.5提供StringFormat属性前，如果我们想对UI上的数据进行格式化，例如， 1,000，一个比较常用的方法是写converter，继承IValueConverter。

有了StringFormat属性就非常的方便了:

<TextBlock Text="{Binding Path=Price, StringFormat='{}{0:C}'}" />
<TextBlock Text="{Binding Path=FormatText, StringFormat='Hello, {0}'}" />

如果考虑到I18N / L10N和集中管理Resource的问题，我们可以使用WPF提供的MarkupExtension.

<TextBlock   Text="{Binding FormatText, StringFormat={ext:Resource Hello_Fomat_Label}}"

定义MarkupExtension:

 

/// <summary>
/// A markup extension that provides simple access to a given
/// entry in the application's <see cref="Resources"/> file.
/// </summary>
public class Resource : MarkupExtension
{
/// <summary>
/// The resource key to be used for the lookup.
/// </summary>
public string ResourceKey { get; set; }

/// <summary>
/// Inits the <see cref="Resource"/> markup extension
/// with the key to be assigned.
/// </summary>
/// <param name="resourceKey">The resource key to be assigned.</param>
public Resource(string resourceKey)
{
ResourceKey = resourceKey;
}

/// <summary>
/// Performs a lookup for the defined <see cref="ResourceKey"/>.
/// </summary>
/// <returns>
/// The value of the resource that is specified by the
/// <see cref="ResourceKey"/> property. If the property is not
/// set, a null reference is returned.
/// </returns>
public override object ProvideValue(IServiceProvider serviceProvider)
{
if (String.IsNullOrEmpty(ResourceKey)) return null;
return Resources.ResourceManager.GetObject(ResourceKey);
}
}

参考：http://www.hardcodet.net/2009/03/lookup-resource-value-using-markup-extension

Designing Database

数据库设计 Step by Step (1)

11 important database designing rules which I follow

Introduction to database design

NHibernate Implementation

这里先整理下学习过程中一些好的文章。

WPF/Silverlight Layout 系统概述——Measure

WPF/Silverlight Layout 系统概述——Arrange

WPF 平移ListBox翻页

WPF中实现自定义虚拟容器(实现VirtualizingPanel)

 

这是一篇受密码保护的文章。您需要提供访问密码：

密码：

The list of breakpoints where the user could control the breakpoint features has been removed, so that now the user can only toggle breakpoints.

The following refactoring modes were also removed:
Encapsulate field
Promote local to parameter
Reorder parameters
Remove parameters
Extract interface

The ability to attach the debugger to an already-running process has also been removed.

Additionally it has been observed that the express version requires that the time between builds be greater than approximately 20 seconds. If a project is rapidly modified and rebuilt the target will not be updated even though the source has been modified and saved.

The major areas where Visual Studio Express lacks features compared to Visual Studio Professional:

No add-ins/macros
Some Win32 tools missing
No Team Explorer support
Limited refactoring support
Debugging is much more limited (particularly problematic for server development is no remote debugging)
Lack of support for setup projects
No report creation tools
No Office development support
No mobile platform support
Limited set of designers
Limited set of database tools
No code profiling or test framework support
No MFC/ATL support
No support for compiling C++ to 64-bit images (workaround is to install Windows SDK which is free)

今天大概的倒腾了下eclipse的颜色配置和常用快捷键的使用。这里总结下吧，有些小问题隐藏的还是比较深的。

1. 颜色配置

Eclipse默认的UI颜色是白色的，看着眼睛不是很舒服。个人比较喜欢VIM经典的黑底颜色方案。

搜了下大都是对Editor的颜色进行了改变，而且都是手工去该的。不过好在我搜到了一个专门的主题插件，爽。。。http://eclipsecolorthemes.org/?view=plugin

这里面有很多方案，只要装下插件，自己选择下就好了。

不过这里还只是对Editor进行配置的，其他的区域没有改，Eclipse Juno 可以写主题了，据说作者开始在搞了。等着了。。。。

2. 快捷键

谷哥和度娘一搜一大堆，没啥好说的。

不过还是遇到了一个小问题，因为我用了搜狗的输入法，所有Ctrl + Shift + Format不好使，改下搜狗的快捷键就可以了。

有句俗语叫：“技多不压身”，如果你有时间和兴趣，不妨多了解和掌握编程技能，或许随时可能有用。本文为你收集了一些编程技巧，让你轻松学编程。

1. Codecademy

在Codecademy学习如何编写激动人心的网页、游戏和程序。通过Codecademy学习编程。简单、互动、有趣，和你的朋友们一起来吧！该网站提供了基于浏览器交互式教程，探讨了基础编程概念以及具备什么样类型，以便你了解编程规则及架构。

2. Udacity

本教程涵盖初、中、高级教程。内容上除了丰富的编程主题还涵盖了物理与统计，教您如何创建一个Web浏览器以及HTML5游戏开发。

3. Code School

Code School提供各种编程课程，包括Ruby， Git，CSS， jQuery等等。有些课程是免费的，有些是需要付费的。非常适合个人与团队，与Code School配套运行的网站有：TryRuby、Rails for Zombies。

4. Treehouse

不管你是新手还是有经验的开发者，本教程都非常适合。Treehouse有两大教程：Silver每月$25，Gold每月$49。允许访问超过700个视频，包括专业人士访谈、项目反馈以及新的想法能够激发你的编程技能。与其他网站一样运行你可以边学边操作。如果你对iOS或Android方面感兴趣，Treehouse是个不错的选择。

5. O’Reilly

本教程涵盖从C语言到数据库管理、PHP、Java等中高级教程。O’Reilly是你的不二选择。

6. Lynda.com

Lynda.com拥有大量的视频教程。你可以使用自己的软件执行文件。内容范围广泛主要有Java，Perl， ASP.net， Ruby以及CS5 PS教程。

7. Google

是的，Google是我们的老朋友了。利用Google编程学院该网站提供辅导手册和示例课程内容，以便学生和教师可以了解有关当前计算技术和范例的详情。尤其是，该内容获得了创造性共用许可，使教师可以轻松地在他们各自的课堂上使用。课程部分包含各种主题领域的教程、演讲幻灯片和问题集，比如AJAX、编程算法、分布式系统、网络安全、语言。

8. Coursera

本教程提供一系列大学教程包括斯坦福，普林斯顿和多伦多大学的课件都是实用的教程，比如，函数式编程Scala，分享具体编程经验。适合不同阶段的学习人员。

本文转自：http://www.csdn.net/article/2012-11-30/2812375-learning-new-programming-skills

英文出自：Itjoblog