"当客户端请求相同的页面时.varnish只发送一个请求到后端(backend)机器,等后面返回数据信息的时候再copy多份\nserve – 服务\nplethora – 过多\nencounter – 遇到\nhopefully – 希望\nGuru – 领袖\nmeditation – 冥想\nrelevant – 有关\nprobably – 可能\nclue – 线索\nransaction – 交易\nelaboration – 拟定\nfurther – 进一步\nvarious – 各种\nDirector – 主任\nresilience – 弹性\ndistribute – 分发\nprobe – 探头\nstale – 陈旧\ncoalesce – 合并\nidentical – 相同\nshield – 盾\nMisbehave – 胡作非为\nability – 能力"

"浅谈伪分布式数据库架构"

"【 导读】\n关于如何构建千万级别用户的后台数据库架构话题，在ITPUB及CSDN论坛都有不少网友提问，新型问答网站知乎上也有人提问，并且顺带梳理了下思路，方便更多的技术朋友有章可循，整理一篇抛砖引玉性的文章。\n一、 技术朋友给出的背景资料：\n(1). 网站型应用，主要指：SNS社交网站、新闻门户型网站、邮件系统、SNS Game社交游戏、电子商务网站、即时通信IM等类型系统；\n(2). 注册用户为千万级别，也即1KW注册用户以内；\n二、要求\n构建千万级别用户的后台数据库架构分析思路，对数据层架构设计的有章可循，必须考虑数据量的大小，以及数据库提供服务的性能和系统的可靠性，适当地考虑用户量超过，以及需要使用的服务器资源等信息。\n三、构建千万级别用户的后台数据库架构的分析思路\n曾经发过一篇文章，关于千万级别用户应用架构设计的歌谣，供大家参考 千万级架构设计诀窍，接下来我们针对如何构建千万级别用户的后台数据库架构，给出通用性分析思路的建议，未必完全靠谱，但求基本靠谱（注：毕竟很多事情需要看具体业务而定的）：\n(1). 一定要区分业务类型，可能达到千万用户级别的应用业务场景，可归类描述为： …"

"示意图： 在使用MySQL的应用中，如果你的MySQL Server压力逐渐增大，在应用层优化已经到了一定瓶颈时，那么你应该首先考虑 MySQL_Replication。本文将利用图示的方式简单的描述出MySQL Replication是如何工作的。\n如何同步\n主库将所有的更新操作，写入二进制日志。 从库运行”IO线程”（Slave IO Thread）读取主库的二进制日志。 从库运行”SQL线程”（Slave SQL Thread）执行IO线程（Slave IO Thread）读取的日志中的SQL,从而保持和主库的一致。 如何分配请求\n目前，这部分需要在应用层实现。 执行更新SQL(UPDATE，INSERT，DELETE)时，请求主库。 执行查询SQL(SELECT)时，请求从库。 所以，当你的应用(Application)SELECT请求所占的比率越大，那么Relication就会越有效。\n相关教程:\nMySQL传输二进制日志原理:"

"摘自:\nMySQL Replication可以很方便的用来做应用的读扩展，也可以帮MySQL实现一定程度的HA方案。MySQL通过向备库传送二进制日志来实现Replication，本文将通过二进制日志相关源代码的主要接口来解释：“MySQL如何传输二进制日志，是主库推，还是备库拉？MySQL日志传输的实时性如何？”。\n在MySQL Replication结构中，备库端初次通过CHANGE MASTER TO完成Replication配置，再使用start slave命令开始复制。更细致的，备库通过IO Thread向主库发起读取binlog的请求（COM_BINLOG_DUMP命令），主库收到COM_BINLOG_DUMP请求后，使用单独线程（dump thread）不断向备库IO Thread发送Binlog。示意图：\n在主库端一旦有新的日志产生后，立刻会发送一次广播，dump线程在收到广播后，则会读取二进制日志并通过网络向备库传输日志，所以这是一个主库向备库不断推送的过程；\n新日志在产生后，只需一次广播和网络就会立刻（\u0026lt;1ms）向发送到备库，如果主备之间网络较好的话（例 …"

"主要有以下动作 pass \\当一个请求被pass后，这个请求将通过varnish转发到后端服务器，但是它不会被缓存。pass可以放在vcl_recv 和 vcl_fetch中。 lookup \\当一个请求在vcl_recv中被lookup后，varnish将从缓存中提取数据，如果缓存中没有数据，将被设置为pass，不能在 vcl_fetch中设置lookup。 pipe \\pipe和 pass相似，都要访问后端服务器，不过当进入pipe 模式后，在此连接未关闭前，后续的所有请求都发到后端服务器（这句是我自己理解后简化的，有能力的朋友可以看看官方文档，给我提修改建议） 。 deliver \\请求的目标被缓存，然后发送给客户端 esi \\ESI-process the fetched document（我理解的就是vcl 中包换一段 html代码）"

"Hitrate ratio由三个数字组成，第一个数字范围0-10，第二个数字范围0-100，第三个数字范围0-1000。\n分别表示过去N秒内的Hitrate avg。上图由于我是刚打开varnishstat，因此三个数字都是4，表示过去4秒内的平均hitrate，如果打开的时间足够长，以上三个数字就会逐渐变成10，100，1000。\nHitrate avg里的内容是命中率，需要乘以100转换成百分比，例如上图表示命中率为99.23%\n接着往下看，三列数据分别表示实时数据，每秒平均值，自启动以来每秒平均值。有些参数是没有后两列的，这是因为这些值都有固定变动范围，例如N work threads，只会在0到最大值（我设的是200）之间变动，搞每秒平均值意义不大（我猜）。\n以下指标需要重点关注一下：\nClient connections accepted: （每秒处理连接数）。 Client requests received：经验表明connection:request=1:10左右时比较理想，比这个数大很多或者小很多都是不好的。代表到目前为止，浏览器向反向代理服务器发送的HTTP请求累积 …"

"●varnishncsa（以 NCSA 的格式显示日志）\nAuthor: Dag-Erling Sm?rgrav\nDate: 2010-05-31\nVersion: 1.0\nManual section: 1\nDisplay varnish logs in apache/NCSA combined log format\nSYNOPSIS\nvarnishncsa [-a] [-b] [-C] [-c] [-D] [-d] [-f] [-I regex] [-i tag]\n[-n varnish_name] [-P file] [-r file] [-V] [-w file] [-X regex] [-x tag]\nDESCRIPTION\nVarnishncsa 工具读取共享内存的日志，然后以 apache/NCSA 的格式显示出来。下 面的选项可以用。\n-a 当把日志写到文件里时，使用附加，而不是覆盖。\n-b 只显示 varnishd 和后端服务器的日志。\n-C 匹配正则表达式的时候，忽略大小写差异。\n-c 只显示 varnishd 和客户端的日志。\n-D 以进程方式运行\n-d 在启动过 …"

"Varnish的一个关键特色就是它有能力防御 web和应用服务器宕机。 Grace mode 当几个客户端请求同一个页面的时候，varnish只发送一个请求到后端服务器，然后让那个其他几个请求挂起等待返回结果，返回结果后，复制请求的结果发送给客户端。 如果您的服务每秒有数千万的点击率，那么这个队列是庞大的，没有用户喜欢等待服务器响应。为了使用过期的 cache 给用户提供服务，我们需要增加他们的 TTL，保存所有cache 中的内容在 TTL过期以后30 分钟内不删除，使用以下VCL：\nsub vcl_fetch { set beresp.grace = 30m; } Varnish 还不会使用过期的目标给用户提供服务，所以我们需要配置以下代码，在cache过期后的15 秒内，使用旧的内容提供服务： sub vcl_recv { set req.grace = 15s; } 你会考虑为什么要多保存过去的内容 30 分钟？当然，如果你使用了健康检查，你可以通过健康状态设置保存的时间：\nif (! req.backend.healthy) { set req.grace = 5m; } …"

"让我们设置一个 director和两个后端，然后加上健康检查：\nbackend server1 { .host = \u0026#34;server1.example.com\u0026#34;; .probe = { .url = \u0026#34;/\u0026#34;; .interval = 5s; .timeout = 1 s; .window = 5; .threshold = 3; } } backend server2 { .host = \u0026#34;server2.example.com\u0026#34;; .probe = { .url = \u0026#34;/\u0026#34;; .interval = 5s; .timeout = 1 s; .window = 5; .threshold = 3; } } 这些新的就是探针，varnish将检查通过探针检查每个后端服务器是否健康：\nurl \\哪个 url需要varnish请求。 Interval \\检查的间隔时间 Timeout \\等待多长时间探针超时 Window \\varnish将维持5个 sliding window的结果 Threshold \\至少有3 次."