Category Archives: 架构

程序员用到的各种优秀资料、神器及框架整理

老司机程序员用到的各种优秀资料、神器及框架整理 | IT瘾

成为一名专业程序员的道路上,需要坚持练习、学习与积累,技术方面既要有一定的广度,更要有自己的深度。

笔者作为一位tool mad,将工作以来用到的各种优秀资料、神器及框架整理在此,毕竟好记性不如烂键盘,此项目可以作为自己的不时之需。

本人喜欢折腾,记录的东西也比较杂,各方面都会有一些,内容按重要等级排序,大家各取所需。

这里的东西会持续积累下去,欢迎Star,也欢迎发PR给我。

目录


<!– END doctoc generated TOC please keep comment here to allow auto update –>

资料篇

技术站点

  • 在线学习: CourseraedXUdacityMIT公开课MOOC学院
  • Hacker News:非常棒的针对编程的链接聚合网站
  • Techmeme:美国知名科技新闻和博客聚集网站,类似的还有(Panda, Hacker & Designer News)
  • Programming reddit:同上
  • Java牛人必备: Program Creek
  • stackoverflow:IT技术问答网站
  • GitHub:全球最大的源代码管理平台,很多知名开源项目都在上面,如Linux内核,OpenStack等
  • LeetCode:来做做这些题吧,看看自己的算法水平如何?这可比什么面试宝典强多了。
  • Kaggle,Topcoder: 机器学习、大数据竞赛
  • 掘金:高质量的技术社区
  • 开发者头条
  • InfoQ:企业级应用,关注软件开发领域
  • V2EX: way to explore
  • 国内老牌技术社区:OSChina、博客园、CSDN、51CTO
  • 免费的it电子书: http://it-ebooks.info/
  • 在线学习: http://www.udemy.com/
  • 优质学习资源: http://plus.mojiax.com/
  • 代码练习: http://exercism.io/ and https://www.codingame.com
  • DevStore:开发者服务商店
  • MSDN:微软相关的官方技术集中地,主要是文档类

必看书籍

  • SICP( Structure and Interpretation of Computer Programs)
  • 深入理解计算机系统
  • 代码大全2
  • 人件
  • 人月神话
  • 软件随想录
  • 算法导论(麻省理工学院出版社)
  • 离线数学及其应用
  • 设计模式
  • 编程之美
  • 黑客与画家
  • 编程珠玑
  • The Little Schemer
  • Simply Scheme_Introducing_Computer_Science
  • C++ Prime
  • Effective C++
  • TCP/IP详解
  • Unix 编程艺术
  • 软件随想录
  • 计算机程序设计艺术
  • 职业篇:程序员的自我修养,程序员修炼之道,高效能程序员的修炼
  • 《精神分析引论》弗洛伊德
  • 《失控》《科技想要什么》《技术元素》凯文凯利
  • 程序开发心理学
  • 天地一沙鸥
  • 搞定:无压力工作的艺术

大牛博客

GitHub篇

学习资料篇

Swift相关

客户端

Framework

小工具

游戏

工作、工具篇

优秀项目篇

工具篇

平台工具

  • Phabricator: 软件开发平台,Facebook出品,现已开源,CodeReview神器(从这个往下一直到GitLab之间的工具统统可以忽略了)
  • Redmine/Trac:项目管理平台
  • Jenkins/Jira(非开源):持续集成系统(Apache Continuum,这个是Apache下的CI系统,还没来得及研究)
  • git,svn:源代码版本控制系统
  • GitLab/Gitorious:构建自己的GitHub服务器
  • Postman:RESTful,api测试工具,HTTP接口开发必备神器
  • Sonar:代码质量管理平台
  • Nessus: 系统漏洞扫描器
  • gitbook: https://www.gitbook.io/写书的好东西,当然用来写文档也很不错的(发现不少产品的文档就是用的它)
  • Travis-ci:开源项目持续集成必备,和GitHub相结合, https://travis-ci.org/
  • Trello:简单高效的项目管理平台,注重看板管理
  • 日志聚合:graylog、ELK(推荐新一代的graylog,基本上算作是开源的Splunk了)
  • 开源测试工具、社区(Selenium、OpenQA.org)
  • Puppet:一个自动管理引擎,可以适用于Linux、Unix以及Windows平台。所谓配置管理系统,就是管理机器里面诸如文件、用户、进程、软件包这些资源。无论是管理1台,还是上万台机器Puppet都能轻松搞定。其他类似工具:CFEngine、SaltStack、Ansible
  • Nagios:系统状态监控报警,还有个Icinga(完全兼容nagios所有的插件,工作原理,配置文件以及方法,几乎一模一样。配置简单,功能强大)
  • Ganglia:分布式监控系统
  • fleet:分布式init系统
  • Ansible:能够大大简化Unix管理员的自动化配置管理与流程控制方式。
  • GeoLite免费数据库
  • jsHint:js代码验证工具
  • haproxy: 高可用负载均衡(此外类似的系统还有nginx,lvs)
  • linux OS性能分析工具:dstat,iostat,iotop,nmon
  • kimono:将网页信息转换为api接口的工具
  • 集群管理工具:pdsh,ClusterSSH,mussh(可以用它快速管理Hadoop集群)ipa-server做统一的认证管理
  • influxdb: 分布式时序数据库,结合Grafana可以进行实时数据分析
  • dot: 程序员绘图利器(是种语言,也是个工具)
  • Graph::Easy: (Ascii Art工具)字符流程图绘制,实乃程序员装逼神器。其他类似的工具Asciiflow, vi插件:drawit!
  • spf13-vim: 让你的vim飞起来!
  • Kubernetes: 容器集群管理系统
  • Gatling: 服务器性能压力测试工具
  • systemtap: Linux内核探测工具、内核调试神器
  • Cygwin:Windows下的类UNIX模拟环境
  • MinGW:Windows下的GNU工具集

常用工具

  • Mac下的神兵利器
  • asciinema: 终端录屏神器
  • Fiddler:非常好用的Web前端调试工具,当然是针对底层http协议的,一般情况使用Chrome等自带的调试工具也足够了,特殊情况还得用它去处理
  • Charles: Mac上的Web代理调试工具,类似Fiddler
  • wireshark:知名的网络数据包分析工具
  • PowerCmd:替代Windows Cmd的利器
  • RegexBuddy:强大的正则表达式测试工具
  • Soure Insight:源代码阅读神器
  • SublimeText:程序员最爱的编辑器
  • Database.NET:一个通用的关系型数据库客户端,基于.NET 4.0开发的,做简单的处理还是蛮方便的
  • Navicat Premium:支持MySql、PostgreSQL、Oracle、Sqlite和SQL Server的客户端,通用性上不如Database.NET,但性能方面比Database.NET好很多,自带备份功能也用于数据库定时备份。
  • Synergy : 局域网内一套键盘鼠标控制多台电脑
  • DameWare:远程协助工具集(我在公司主要控制大屏幕用)
  • Radmin: 远程控制工具,用了一段时间的DameWare,还要破解,对Win7支持的不好,还是发现这个好用
  • Listary:能极大幅度提高你 Windows 文件浏览与搜索速度效率的「超级神器」
  • Clover:给资源管理器加上多标签,我平时工作的时候就用它,像Chrome一样使用资源管理器,甚是方便啊(这是Windows平台的)
  • WinLaunch:模拟Mac OS的Launch工具
  • Fritzing:绘制电路图
  • LICEcap:gif教程制作
  • git,svn:版本控制系统
  • Enigma Virtual Box(将exe,dll等封装成一个可执行程序)
  • Open DBDiff(针对SqlServer)数据库同步
  • SymmetricDS:数据库同步
  • BIEE,Infomatica,SPSS,weka,R语言:数据分析
  • CodeSmith,LightSwitch:代码生成
  • Pandoc:Markdown转换工具,出书用的。以前玩过docbook,不过现在还是Markdown盛行啊。
  • Window Magnet[Mac]:增强Mac窗口管理功能,想Win7一样具有窗口拖放到屏幕边缘自动调整的功能
  • log explorer:查看SqlServer日志
  • dependency walker:查询Windows应用程序dll依赖项
  • Shairport4w:将iPhone,iPad,iPod上的音频通过AirPlay协议传输到PC上
  • ngrok:内网穿透工具
  • Axure:快速原型制作工具,还有个在线作图的工具国内的一个创业团队做的,用着很不错 http://www.processon.com/
  • Origami: 次世代交互设计神器
  • 百度脑图: http://naotu.baidu.com/
  • tinyproxy:(Linux)小型的代理服务器支持http和https协议
  • EaseUS Partition Master:超级简单的分区调整工具,速度还是蛮快的,C盘不够用了就用它从D盘划点空间吧,不用重装系统这么折腾哦。
  • CheatEngine:玩游戏修改内存值必备神器(记得我在玩轩辕剑6的时候就用的它,超级方便呢)
  • ApkIDE:Android反编译神器
  • 翻、墙工具(自|由|门、天行浏览器,免费的VPN: http://www.mangovpn.com/),发现最方便还属Lantern,免费用起来超级方便(更新于2015-08-22)
  • 设计工具:Sketch、OmniGraffle
  • MindManger:思维导图
  • MagicDraw:Uml图工具
  • innotop:MySql状态监测工具
  • 墨刀:比Axure更为简单的原型工具,可以快速制作原型
  • Karabiner: Mac专用,修改键盘键位的神器,机械键盘必备
  • Timing:Mac专用,统计你的时间都花在哪了
  • f.lux: 护眼神器,过滤蓝光,程序员护眼必备良品
  • LaTeX: 基于ΤΕΧ的排版系统, 让写论文更方便
  • Antlr:开源的语法分析器,可以让你毫无压力的写个小parser

第三方服务

  • DnsPod:一个不错的只能DNS服务解析提供商
  • DigitalOcean:海外的云主机提供商,价格便宜,磁盘是SSD的,用过一段时间整体上还可以,不过毕竟是海外的,网速比较慢。国内的就是阿里云了。还有个比较知名的是:Linode,据说速度上比DigitalOcean好很多
  • 移动端推送服务:个推、JPush、云巴
  • LeanCloud:移动应用开发服务,包括:数据存储、用户管理、消息推送、应用统计、社交分享、实时聊天等服务
  • Color Hunt: 漂亮炫酷的配色网站,程序员的福音
  • Heroku: PaaS平台

爬虫相关(好玩的工具)

  • Phantomjs(Web自动化测试,服务端渲染等)
  • berserkJS(基于Phantomjs的改进版本)
  • SlimerJS
  • CasperJS
  • selenium
  • HtmlUnit(开源的java 页面分析工具,也是个Headless的浏览器)

安全相关

  • sql注入检测:sqlmap、haviji
  • 端口扫描:nmap
  • 渗透测试:BurpLoader
  • sqltools: sql漏洞利用工具
  • snort: 入侵检测

Web服务器性能/压力测试工具/负载均衡器

  • ab: ab是apache自带的一款功能强大的测试工具
  • curl-loader: 真实模拟、测试Web负载
  • http_load: 程序非常小,解压后也不到100K
  • webbench: 是Linux下的一个网站压力测试工具,最多可以模拟3万个并发连接去测试网站的负载能力。
  • Siege: 一款开源的压力测试工具,可以根据配置对一个WEB站点进行多用户的并发访问,记录每个用户所有请求过程的相应时间,并在一定数量的并发访问下重复进行。
  • squid(前端缓存),nginx(负载),nodejs(没错它也可以,自己写点代码就能实现高性能的负载均衡器):常用的负载均衡器
  • Piwik:开源网站访问量统计系统
  • ClickHeat:开源的网站点击情况热力图
  • HAProxy:高性能TCP /HTTP负载均衡器
  • ElasticSearch:搜索引擎基于Lucene
  • Page Speed SDK和YSLOW
  • HAR Viewer: HAR分析工具
  • protractor:E2E(end to end)自动化测试工具

大数据处理/数据分析/分布式工具

  • Hadoop:分布式的文件系统,结合其MapReduce编程模型可以用来做海量数据的批处理(Hive,Pig,HBase啥的就不说了),值得介绍的是Cloudera的Hadoop分支CDH5,基于YARN MRv2集成了Spark可直接用于生产环境的Hadoop,对于企业快速构建数据仓库非常有用。
  • Spark:大规模数据处理框架(可以应付企业中常见的三种数据处理场景:复杂的批量数据处理(batch data processing);基于历史数据的交互式查询(interactive query);基于实时数据流的数据处理(streaming data processing)),CSND有篇文章介绍的不错
  • 除了Spark,其他几个不错的计算框架还有:Kylin,Flink,Drill
  • Ceph:Linux分布式文件系统(特点:无中心)
  • Storm:实时流数据处理,可以看下IBM的一篇介绍 (还有个Yahoo的S4,也是做流数据处理的)
  • Druid: 实时数据分析存储系统
  • Ambari: 大数据平台搭建、监控利器;类似的还有CDH
  • Tachyon:分布式内存文件系统
  • Mesos:计算框架一个集群管理器,提供了有效的、跨分布式应用或框架的资源隔离和共享
  • Impala:新一代开源大数据分析引擎,提供Sql语义,比Hive强在速度上
  • presto: facebook的开源工具,大数据分布式sql查询引擎
  • SNAPPY:快速的数据压缩系统,适用于Hadoop生态系统中
  • Kafka:高吞吐量的分布式消息队列系统
  • ActiveMQ:是Apache出品,最流行的,能力强劲的开源消息总线
  • MQTT:Message Queuing Telemetry Transport,消息队列遥测传输)是IBM开发的一个即时通讯协议,有可能成为物联网的重要组成部分
  • RabbitMQ:记得OpenStack就是用的这个东西吧
  • ZeroMQ:宣称是将分布式计算变得更简单,是个分布式消息队列,可以看下云风的一篇文章的介绍
  • 开源的日志收集系统:scribe、chukwa、kafka、flume。这有一篇对比文章
  • Zookeeper:可靠的分布式协调的开源项目
  • Databus:LinkedIn 实时低延迟数据抓取系统
  • 数据源获取:Flume、Google Refine、Needlebase、ScraperWiki、BloomReach
  • 序列化技术:JSON、BSON、Thrift、Avro、Google Protocol Buffers
  • NoSql:ScyllaDB(宣称是世界上最快的NoSql)、Apache Casandra、MongoDB、Apache CouchDB、Redis、BigTable、HBase、Hypertable、Voldemort、Neo4j
  • MapReduce相关:Hive、Pig、Cascading、Cascalog、mrjob、Caffeine、S4、MapR、Acunu、Flume、Kafka、Azkaban、Oozie、Greenplum
  • 数据处理:R、Yahoo! Pipes、Mechanical Turk、Solr/ Lucene、ElasticSearch、Datameer、Bigsheets、Tinkerpop
  • NLP自然语言处理:Natural Language Toolkit、Apache OpenNLP、Boilerpipe、OpenCalais
  • 机器学习:TensorFlow(Google出品),WEKA、Mahout、scikits.learn、SkyTree
  • 可视化技术:GraphViz、Processing、Protovis、Google Fusion Tables、Tableau、Highcharts、EChats(百度的还不错)、Raphaël.js
  • Kettle:开源的ETL工具
  • Pentaho:以工作流为核心的开源BI系统
  • Mondrian:开源的Rolap服务器
  • Oozie:开源hadoop的工作流调度引擎,类似的还有:Azkaban
  • 开源的数据分析可视化工具:Weka、Orange、KNIME
  • Cobar:阿里巴巴的MySql分布式中间件
  • 数据清洗:data wrangler, Google Refine

Web前端

  • Material Design: 谷歌出品,必属精品
  • Vue.js: 借鉴了Angular及React的JS框架,设计理念较为先进
  • GRUNT: js task runner
  • Sea.js: js模块化
  • knockout.js:MVVM开发前台,绑定技术
  • Angular.js: 使用超动感HTML & JS开发WEB应用!
  • Highcharts.js,Flot:常用的Web图表插件
  • NVD3: 基于d3.js的图表库
  • Raw:非常不错的一款高级数据可视化工具
  • Rickshaw:时序图标库,可用于构建实时图表
  • JavaScript InfoVis Toolkit:另一款Web数据可视化插件
  • Pdf.js,在html中展现pdf
  • ACE,CodeMirror:Html代码编辑器(ACE甚好啊)
  • NProcess:绚丽的加载进度条
  • impress.js:让你制作出令人眩目的内容展示效果(类似的还有reveal)
  • Threejs:3DWeb库
  • Hightopo:基于Html5的2D、3D可视化UI库
  • jQuery.dataTables.js:高度灵活的表格插件
  • Raphaël:js,canvas绘图库,后来发现百度指数的图形就是用它绘出来的
  • director.js:js路由模块,前端路由,Nodejs后端路由等,适合构造单页应用
  • pace.js:页面加载进度条
  • bower:Web包管理器
  • jsnice:有趣的js反编译工具,猜压缩后的变量名, http://www.jsnice.org/
  • D3.js: 是一个基于JavaScript数据展示库(类似的还有P5.js)
  • Zepto.js:移动端替代jQuery的东东,当然也可以使用jquery-mobile.
  • UI框架:Foundation,Boostrap,Pure,EasyUI,Polymer
  • 前段UI设计师必去的几个网站:Dribbble,awwwards,unmatchedstyle,UIMaker
  • Mozilla 开发者中心: https://developer.mozilla.org/en-US/
  • 图标资源:IcoMoon(我的最爱),Font Awesome, Themify Icons,FreePik,Glyphicons
  • artDialog:非常漂亮的对话框
  • AdminLTE:github上的一个开源项目,基于Boostrap3的后台管理页面框架
  • Respond.js:让不懂爱的IE6-8支持响应式设计
  • require.js: js模块加载库
  • select2:比chosen具有更多特性的选择框替代库
  • AngularUI:集成angular.js的UI库
  • normalize.css: 采用了现代化标准让各浏览器渲染出的html保持一致的库
  • CreateJS:Html5游戏引擎
  • Less,Compass:简化CSS开发
  • emojify.js:用于自动识别网页上的Emoji文字并将其显示为图像
  • simditor:一个不错的开源的html编辑器,简洁高效
  • Sencha: 基于html5的移动端开发框架
  • SuperScrollorama+TweenMax+skrollr:打造超酷的视差滚动效果网页动画
  • jquery-smooth-scroll:同上,平滑滚动插件
  • Animate.css:实现了各种动画效果的css库
  • Emmet:前端工程师必备,ZenCode的前身
  • React: facebook出品的js UI库
  • highlight.js:专门用来做语法高亮的库
  • GoJS: Html5交互式图表库,看demo更适合层次结构的图表。
  • 10 Pure CSS (Mostly) Flat Mobile Devices: http://marvelapp.github.io/devices.css/
  • CodePen: http://codepen.io/
  • jsfiddle: http://jsfiddle.net/ 前端js,html,css测试利器

语言篇

折腾中:Scala、Python、Lua、JavaScript、Go

待折腾:

Scala

Java

  • 常用的IDE:IntelliJ IDEA(强烈推荐),Eclipse,Netbeans
  • fastutil: 性能更好的Java集合框架
  • Guava: 谷歌的Java工具包,应用广泛
  • Curator:Netflix公司开源的一个Zookeeper client library,用于简化Zookeeper客户端编程,现在已经是apache下的一个独立项目了。Spark的HA也用的这货。
  • Rx(Reactive Extensions)框架:Vert.x, RxJava(Android中用的比较多), Quasar
  • FindBugs: 代码静态分析工具,找出代码缺陷
  • Java反编译工具:Luyten,JD-Gui
  • Drools: 规则引擎
  • Jersey: Java RESTful 框架
  • canal: 阿里巴巴出品,binlog增量订阅&消费组件
  • Web开发相关:Tomcat、Resin、Jetty、WebLogic等,常用的组件Struts,Spring,Hibernate
  • Netty: 异步事件驱动网络应用编程框架,用于高并发网络编程比较好(NIO框架,spark 1.2.0就用netty替代了nio)
  • MINA:简单地开发高性能和高可靠性的网络应用程序(也是个NIO框架),不少手游服务端是用它开发的
  • jOOQ:java Orm框架
  • Janino: 超级小又快的Java编译器,Spark的Tungsten引起用的它
  • Activiti:工作流引擎,类似的还有jBPM、Snaker
  • Perfuse:是一个用户界面包用来把有结构与无结构数据以具有交互性的可视化图形展示出来.
  • Gephi:复杂网络分析软件, 其主要用于各种网络和复杂系统,动态和分层图的交互可视化与探测开源工具
  • Nutch:知名的爬虫项目,hadoop就是从这个项目中发展出来的
  • web-harvest:Web数据提取工具
  • POM工具:Maven+Artifactory
  • Akka:一款基于actor模型实现的 并发处理框架
  • EclEmma:覆盖测试工具
  • Shiro:安全框架
  • joda-time:简化时间处理
  • parboiled:表达式解析
  • dozer: 深拷贝神器
  • dubbo: 阿里巴巴出品的分布式服务框架
  • jackson databind: json序列化工具(fastjson,simplejson)
  • Atomikos: 分布式事务管理
  • BoneCP:性能很赞的数据库连接池组件,据说比c3p0快好多
  • ProGuard: obconfuscation tool, 强大的混淆工具
  • S-99:Scala相关的99个问题

Python

  • PyCharm:最佳Python IDE
  • Eric,Eclipse+pydev,比较不错的Python IDE
  • PyWin:Win32 api编程包
  • numpy:科学计算包,主要用来处理大型矩阵计算等,此外还有SciPy,Matplotlib
  • GUI相关:PyQt,PyQwt
  • supervisor:进程监控工具
  • PyGame: 基于Python的多媒体开发和游戏软件开发模块
  • Web框架: Django 开源web开发框架,它鼓励快速开发,并遵循MVC设计

.NET

  • Xilium.CefGlue:基于CEF框架的.NET封装,基于.NET开发Chrome内核浏览器
  • CefSharp:同上,有一款WebKit的封装,C#和Js交互会更简单
  • netz:免费的 .NET 可执行文件压缩工具
  • SmartAssembly:变态的.net代码优化混淆工具
  • NETDeob0:.net反混淆工具,真是魔高一尺道高一丈啊(还有个de4dot,在GitHub上,都是开源的)
  • ILMerge:将所有引用的DLL和exe文件打成一个exe文件
  • ILSpy:开源.net程序反编译工具
  • Javascript.NET:很不错的js执行引擎,对v8做了封装
  • NPOI: Excel操作
  • DotRAS:远程访问服务的模块
  • WinHtmlEditor: Winform下的html编辑器
  • SmartThreadPool:使用C#实现的,带高级特性的线程池
  • Snoop: WPF Spy Utility
  • Autofac: 轻量级IoC框架
  • HtmlAgilityPack:Html解析利器
  • Quartz.NET:Job调度
  • HttpLib:@CodePlex,简化http请求
  • SuperSocket:简化Socket操作,基于他的还有个SuperWebSocket,可以开发独立的WebSocket服务器了
  • DocX:未安装Office的情况下操作Word文件
  • Dapper:轻量级的ORM类,性能不错
  • HubbleDotNet:支持接入数据库的全文搜索系统
  • fastJSON:@CodeProject,高性能的json序列化类
  • ZXing.NET:@CodePlex,QR,条形码相关
  • Nancy:轻量级Http服务器,做个小型的Web应用可以摆脱IIS喽(Nancy.Viewengines.Razor,可以加入Razor引擎)
  • AntiXSS:微软的XSS防御库Microsoft Web Protection Library
  • Jint:JavaScript解释器
  • CS-Script:将C#代码文件作为脚本执行
  • Jexus:Linux下 高性能、易用、免费的ASP.NET服务器
  • Clay:将dynamic发挥的更加灵活,像写js一样写C#
  • DynamicJSON:不必定义数据模型获取json数据
  • SharpPcap:C#版的WinPcap调用端,牛逼的网络包分析库(自带PacketNotNet用于包协议分析)
  • Roslyn:C#,VB编译器
  • ImageResizer: 服务端自由控制图片大小,真乃神器也,对手机端传小图,PC端传大图,CMS用它很方便
  • UI相关:DevExpress, Fluent(Office 07风格), mui(Modern UI for WPF)
  • NetSparkle:应用自动更新组件
  • ConfuserEx: 开源.net混淆工具
  • ServiceStack: 开源高性能Web服务框架,可用于构建高性能的REST服务
  • Expression Evaluator:Eval for C#,处理字符串表达式
  • http://nugetmusthaves.com/
  • Reactive Extensions (Rx):异步,事件驱动编程包, Rx = Observables + LINQ + Schedulers

C & C++

  • Thrift:用来进行可扩展且跨语言的服务的开发(类似的还有个Avro,Google protobuf)。
  • libevent:是一个事件触发的网络库,适用于windows、linux、bsd等多种平台,内部使用select、epoll、kqueue等系统调用管理事件机制。(对了还有个libev呢)
  • Boost:不多说了,准C++标准库
  • Valgrind/Ptmalloc/Purify: 调试工具
  • NetworkServer架构:acceptor->dispatcher->worker(这个不算工具哦)
  • breakpad:崩溃转储和分析模块,很多crashreport会用到
  • UI界面相关:MFC、BCG和QT这类的就不说了,高端一点的还有Html和DirectUI技术:libcef(基于chrome内核的,想想使用html5开发页面,还真有点小激动呢)、HtmlLayout、Duilib、Bolt,非C++的,还有node-webkit也不错,集成了node和webkit内核。

其他

游戏开发相关

  • MINA:使用Java开发手游和页游服务器(对了还有Netty,也很猛的,都是基于NIO的)
  • HP-Socket:见有有些页游服务器使用这个构建的
  • Unreal: 虚幻引擎,C++,基于这个引擎的游戏很多
  • OGRE:大名鼎鼎的3D图形渲染引擎,天龙八部OL、火炬之光等不少游戏都用了这个引擎
  • OpenVDB:梦工厂C++的特效库,开源的
  • cocos2d:跨平台2D游戏引擎
  • unity3d:跨平台3D游戏引擎,很火的哦
  • Nodejs:也有不少使用它来开发手游和也有服务器(网易的Pomelo)

日志聚合,分布式日志收集

  • Scribe:Facebook的(nodejs + scribe + inotify 同步日志)
  • logstash:强大的日志收集系统,可以基于logstash+kibana+elasticsearch+redis开发强大的日志分析平台
  • log.io: nodejs开发的实时日志收集系统

RTP,实时传输协议与音视频

  • RTP,RTCP,RTSP-> librtp,JRTPLIB(遵循了RFC1889标准)
  • 环形缓冲区,实时数据传输用
  • SDL,ffmpeg,live555,Speex
  • Red5:用Java开发开源的Flash流媒体服务器。它支持:把音频(MP3)和视频(FLV)转换成播放流; 录制客户端播放流(只支持FLV);共享对象;现场直播流发布;远程调用。

from:http://itindex.net/detail/56707-%E8%80%81%E5%8F%B8-%E7%A8%8B%E5%BA%8F%E5%91%98-%E8%B5%84%E6%96%99

扛住100亿次请求?我们来试一试

作者:ppmsn2005#gmail.com
项目: https://github.com/xiaojiaqi/10billionhongbaos
wiki: https://github.com/xiaojiaqi/10billionhongbaos/wiki/扛住100亿次请求?我们来试一试

1. 前言

前几天,偶然看到了 《扛住100亿次请求——如何做一个“有把握”的春晚红包系统”》(url)一文,看完以后,感慨良多,收益很多。正所谓他山之石,可以攻玉,虽然此文发表于2015年,我看到时已经是2016年末,但是其中的思想仍然是可以为很多后端设计借鉴,。同时作为一个工程师,看完以后又会思考,学习了这样的文章以后,是否能给自己的工作带来一些实际的经验呢?所谓纸上得来终觉浅,绝知此事要躬行,能否自己实践一下100亿次红包请求呢?否则读完以后脑子里能剩下的东西 不过就是100亿 1400万QPS整流 这样的字眼,剩下的文章将展示作者是如何以此过程为目标,在本地环境的模拟了此过程。

实现的目标: 单机支持100万连接,模拟了摇红包和发红包过程,单机峰值QPS 6万,平稳支持了业务。

注:本文以及作者所有内容,仅代表个人理解和实践,过程和微信团队没有任何关系,真正的线上系统也不同,只是从一些技术点进行了实践,请读者进行区分。因作者水平有限,有任何问题都是作者的责任,有问题请联系 ppmsn2005#gmail.com. 全文内容 扛住100亿次请求?我们来试一试

2. 背景知识

QPS: Queries per second 每秒的请求数目

PPS:Packets per second 每秒数据包数目

摇红包:客户端发出一个摇红包的请求,如果系统有红包就会返回,用户获得红包

发红包:产生一个红包里面含有一定金额,红包指定数个用户,每个用户会收到红包信息,用户可以发送拆红包的请求,获取其中的部分金额。

3. 确定目标

在一切系统开始以前,我们应该搞清楚我们的系统在完成以后,应该有一个什么样的负载能力。

3.1 用户总数:

通过文章我们可以了解到接入服务器638台, 服务上限大概是14.3亿用户, 所以单机负载的用户上限大概是14.3亿/638台=228万用户/台。但是目前中国肯定不会有14亿用户同时在线,参考 http://qiye.qianzhan.com/show/detail/160818-b8d1c700.html 的说法,2016年Q2 微信用户大概是8亿,月活在5.4 亿左右。所以在2015年春节期间,虽然使用的用户会很多,但是同时在线肯定不到5.4亿。

3.2. 服务器数量:

一共有638台服务器,按照正常运维设计,我相信所有服务器不会完全上线,会有一定的硬件冗余,来防止突发硬件故障。假设一共有600台接入服务器。

3.3 单机需要支持的负载数:

每台服务器支持的用户数:5.4亿/600 = 90万。也就是平均单机支持90万用户。如果真实情况比90万更多,则模拟的情况可能会有偏差,但是我认为QPS在这个实验中更重要。

3.4. 单机峰值QPS:

文章中明确表示为1400万QPS.这个数值是非常高的,但是因为有600台服务器存在,所以单机的QPS为 1400万/600= 约为2.3万QPS, 文章曾经提及系统可以支持4000万QPS,那么系统的QPS 至少要到4000万/600 = 约为 6.6万, 这个数值大约是目前的3倍,短期来看并不会被触及。但是我相信应该做过相应的压力测试。

3.5. 发放红包:

文中提到系统以5万个每秒的下发速度,那么单机每秒下发速度50000/600 =83个/秒,也就是单机系统应该保证每秒以83个的速度下发即可。
最后考虑到系统的真实性,还至少有用户登录的动作,拿红包这样的业务。真实的系统还会包括聊天这样的服务业务。

最后整体的看一下 100亿次摇红包这个需求,假设它是均匀地发生在春节联欢晚会的4个小时里,那么服务器的QPS 应该是10000000000/600/3600/4.0=1157. 也就是单机每秒1000多次,这个数值其实并不高。如果完全由峰值速度1400万消化 10000000000/(1400*10000) = 714秒,也就是说只需要峰值坚持11分钟,就可以完成所有的请求。可见互联网产品的一个特点就是峰值非常高,持续时间并不会很长。

总结:

从单台服务器看.它需要满足下面一些条件
1. 支持至少100万连接用户
2. 每秒至少能处理2.3万的QPS,这里我们把目标定得更高一些 分别设定到了3万和6万。
3. 摇红包:支持每秒83个的速度下发放红包,也就是说每秒有2.3万次摇红包的请求,其中83个请求能摇到红包,其余的2.29万次请求会知道自己没摇到。当然客户端在收到红包以后,也需要确保客户端和服务器两边的红包数目和红包内的金额要一致。因为没有支付模块,所以我们也把要求提高一倍,达到200个红包每秒的分发速度
4. 支持用户之间发红包业务,确保收发两边的红包数目和红包内金额要一致。同样也设定200个红包每秒的分发速度为我们的目标。

想完整模拟整个系统实在太难了,首先需要海量的服务器,其次需要上亿的模拟客户端。这对我来说是办不到,但是有一点可以确定,整个系统是可以水平扩展的,所以我们可以模拟100万客户端,在模拟一台服务器 那么就完成了1/600的模拟。

和现有系统区别:
和大部分高QPS测试的不同,本系统的侧重点有所不同。我对2者做了一些对比。

常见高QPS系统压力测试 本系统压力测试
连接数 一般<1000 (几百以内) 1000000 (1百万)
单连接吞吐量 非常大 每个连接几十M字节吞吐 非常小 每个连接每次几十个字节
需要的IO次数 不多 非常多

4. 基础软件和硬件

4.1软件:

Golang 1.8r3 , shell, python (开发没有使用c++ 而是使用了golang, 是因为使用golang 的最初原型达到了系统要求。虽然golang 还存在一定的问题,但是和开发效率比,这点损失可以接受)
服务器操作系统:
Ubuntu 12.04
客户端操作系统:
debian 5.0

4.2硬件环境

服务端: dell R2950。 8核物理机,非独占有其他业务在工作,16G内存。这台硬件大概是7年前的产品,性能应该不是很高要求。
服务器硬件版本:
machine
服务器CPU信息:
cpu

客户端: esxi 5.0 虚拟机,配置为4核 5G内存。一共17台,每台和服务器建立6万个连接。完成100万客户端模拟

5. 技术分析和实现

5.1) 单机实现100万用户连接

这一点来说相对简单,笔者在几年前就早完成了单机百万用户的开发以及操作。现代的服务器都可以支持百万用户。相关内容可以查看   github代码以及相关文档。
https://github.com/xiaojiaqi/C1000kPracticeGuide
系统配置以及优化文档:
https://github.com/xiaojiaqi/C1000kPracticeGuide/tree/master/docs/cn

5.2) 3万QPS

这个问题需要分2个部分来看客户端方面和服务器方面。

客户端QPS

因为有100万连接连在服务器上,QPS为3万。这就意味着每个连接每33秒,就需要向服务器发一个摇红包的请求。因为单IP可以建立的连接数为6万左右, 有17台服务器同时模拟客户端行为。我们要做的就保证在每一秒都有这么多的请求发往服务器即可。
其中技术要点就是客户端协同。但是各个客户端的启动时间,建立连接的时间都不一致,还存在网络断开重连这样的情况,各个客户端如何判断何时自己需要发送请求,各自该发送多少请求呢?

我是这样解决的:利用NTP服务,同步所有的服务器时间,客户端利用时间戳来判断自己的此时需要发送多少请求。
算法很容易实现:
假设有100万用户,则用户id 为0-999999.要求的QPS为5万, 客户端得知QPS为5万,总用户数为100万,它计算 100万/5万=20,所有的用户应该分为20组,如果 time() % 20 == 用户id % 20,那么这个id的用户就该在这一秒发出请求,如此实现了多客户端协同工作。每个客户端只需要知道 总用户数和QPS 就能自行准确发出请求了。
(扩展思考:如果QPS是3万 这样不能被整除的数目,该如何办?如何保证每台客户端发出的请求数目尽量的均衡呢?)

服务器QPS

服务器端的QPS相对简单,它只需要处理客户端的请求即可。但是为了客观了解处理情况,我们还需要做2件事情。
第一: 需要记录每秒处理的请求数目,这需要在代码里埋入计数器。
第二: 我们需要监控网络,因为网络的吞吐情况,可以客观的反映出QPS的真实数据。为此,我利用python脚本 结合ethtool 工具编写了一个简单的工具,通过它我们可以直观的监视到网络的数据包通过情况如何。它可以客观的显示出我们的网络有如此多的数据传输在发生。
工具截图: 工具截图

5.3) 摇红包业务

摇红包的业务非常简单,首先服务器按照一定的速度生产红包。红包没有被取走的话,就堆积在里面。服务器接收一个客户端的请求,如果服务器里现在有红包就会告诉客户端有,否则就提示没有红包。
因为单机每秒有3万的请求,所以大部分的请求会失败。只需要处理好锁的问题即可。
我为了减少竞争,将所有的用户分在了不同的桶里。这样可以减少对锁的竞争。如果以后还有更高的性能要求,还可以使用 高性能队列——Disruptor来进一步提高性能。

注意,在我的测试环境里是缺少支付这个核心服务的,所以实现的难度是大大的减轻了。另外提供一组数字:2016年淘宝的双11的交易峰值仅仅为12万/秒,微信红包分发速度是5万/秒,要做到这点是非常困难的。(http://mt.sohu.com/20161111/n472951708.shtml)

5.4) 发红包业务

发红包的业务很简单,系统随机产生一些红包,并且随机选择一些用户,系统向这些用户提示有红包。这些用户只需要发出拆红包的请求,系统就可以随机从红包中拆分出部分金额,分给用户,完成这个业务。同样这里也没有支付这个核心服务。

5.5)监控

最后 我们需要一套监控系统来了解系统的状况,我借用了我另一个项目(https://github.com/xiaojiaqi/fakewechat) 里的部分代码完成了这个监控模块,利用这个监控,服务器和客户端会把当前的计数器内容发往监控,监控需要把各个客户端的数据做一个整合和展示。同时还会把日志记录下来,给以后的分析提供原始数据。 线上系统更多使用opentsdb这样的时序数据库,这里资源有限,所以用了一个原始的方案

监控显示日志大概这样
监控日志

6. 代码实现及分析

在代码方面,使用到的技巧实在不多,主要是设计思想和golang本身的一些问题需要考虑。
首先golang的goroutine 的数目控制,因为至少有100万以上的连接,所以按照普通的设计方案,至少需要200万或者300万的goroutine在工作。这会造成系统本身的负担很重。
其次就是100万个连接的管理,无论是连接还是业务都会造成一些心智的负担。
我的设计是这样的:

架构图

首先将100万连接分成多个不同的SET,每个SET是一个独立,平行的对象。每个SET 只管理几千个连接,如果单个SET 工作正常,我只需要添加SET就能提高系统处理能力。
其次谨慎的设计了每个SET里数据结构的大小,保证每个SET的压力不会太大,不会出现消息的堆积。
再次减少了gcroutine的数目,每个连接只使用一个goroutine,发送消息在一个SET里只有一个gcroutine负责,这样节省了100万个goroutine。这样整个系统只需要保留 100万零几百个gcroutine就能完成业务。大量的节省了cpu 和内存
系统的工作流程大概如下:
每个客户端连接成功后,系统会分配一个goroutine读取客户端的消息,当消息读取完成,将它转化为消息对象放至在SET的接收消息队列,然后返回获取下一个消息
在SET内部,有一个工作goroutine,它只做非常简单而高效的事情,它做的事情如下,检查SET的接受消息,它会收到3类消息

1, 客户端的摇红包请求消息

2, 客户端的其他消息 比如聊天 好友这一类

3, 服务器端对客户端消息的回应

对于 第1种消息 客户端的摇红包请求消息 是这样处理的,从客户端拿到摇红包请求消息,试图从SET的红包队列里 获取一个红包,如果拿到了就把红包信息 返回给客户端,否则构造一个没有摇到的消息,返回给对应的客户端。
对于第2种消息 客户端的其他消息 比如聊天 好友这一类,只需简单地从队列里拿走消息,转发给后端的聊天服务队列即可,其他服务会把消息转发出去。
对于第3种消息 服务器端对客户端消息的回应。SET 只需要根据消息里的用户id,找到SET里保留的用户连接对象,发回去就可以了。

对于红包产生服务,它的工作很简单,只需要按照顺序在轮流在每个SET的红包产生对列里放至红包对象就可以了。这样可以保证每个SET里都是公平的,其次它的工作强度很低,可以保证业务稳定。

见代码
https://github.com/xiaojiaqi/10billionhongbaos

7实践

实践的过程分为3个阶段

阶段1:

分别启动服务器端和监控端,然后逐一启动17台客户端,让它们建立起100万的链接。在服务器端,利用ss 命令 统计出每个客户端和服务器建立了多少连接。
命令如下:
Alias ss2=Ss –ant | grep 1025 | grep EST | awk –F: “{print \$8}” | sort | uniq –c’

结果如下: 100万连接建立

阶段2:

利用客户端的http接口,将所有的客户端QPS 调整到3万,让客户端发出3W QPS强度的请求。
运行如下命令:
启动脚本

观察网络监控和监控端反馈,发现QPS 达到预期数据
网络监控截图
3万qps

在服务器端启动一个产生红包的服务,这个服务会以200个每秒的速度下发红包,总共4万个。此时观察客户端在监控上的日志,会发现基本上以200个每秒的速度获取到红包。

摇红包

等到所有红包下发完成后,再启动一个发红包的服务,这个服务系统会生成2万个红包,每秒也是200个,每个红包随机指定3位用户,并向这3个用户发出消息,客户端会自动来拿红包,最后所有的红包都被拿走。

发红包

阶段3

利用客户端的http接口,将所有的客户端QPS 调整到6万,让客户端发出6W QPS强度的请求。

6wqps

如法炮制,在服务器端,启动一个产生红包的服务,这个服务会以200个每秒的速度下发红包。总共4万个。此时观察客户端在监控上的日志,会发现基本上以200个每秒的速度获取到红包。
等到所有红包下发完成后,再启动一个发红包的服务,这个服务系统会生成2万个红包,每秒也是200个,每个红包随机指定3位用户,并向这3个用户发出消息,客户端会自动来拿红包,最后所有的红包都被拿走。

最后,实践完成。

8 分析数据

在实践过程中,服务器和客户端都将自己内部的计数器记录发往监控端,成为了日志。我们利用简单python 脚本和gnuplt 绘图工具,将实践的过程可视化,由此来验证运行过程。

第一张是 客户端的QPS发送数据
客户端qps
这张图的横坐标是时间,单位是秒,纵坐标是QPS,表示这时刻所有客户端发送的请求的QPS。
图的第一区间,几个小的峰值,是100万客户端建立连接的, 图的第二区间是3万QPS 区间,我们可以看到数据 比较稳定的保持在3万这个区间。最后是6万QPS区间。但是从整张图可以看到QPS不是完美地保持在我们希望的直线上。这主要是以下几个原因造成的

  1. 当非常多goroutine 同时运行的时候,依靠sleep 定时并不准确,发生了偏移。我觉得这是golang本身调度导致的。当然如果cpu比较强劲,这个现象会消失。
  2. 因为网络的影响,客户端在发起连接时,可能发生延迟,导致在前1秒没有完成连接。
  3. 服务器负载较大时,1000M网络已经出现了丢包现象,可以通过ifconfig 命令观察到这个现象,所以会有QPS的波动。

第二张是 服务器处理的QPS图
服务器qps

和客户端的向对应的,服务器也存在3个区间,和客户端的情况很接近。但是我们看到了在大概22:57分,系统的处理能力就有一个明显的下降,随后又提高的尖状。这说明代码还需要优化。

整体观察在3万QPS区间,服务器的QPS比较稳定,在6万QSP时候,服务器的处理就不稳定了。我相信这和我的代码有关,如果继续优化的话,还应该能有更好的效果。

将2张图合并起来 qps

基本是吻合的,这也证明系统是符合预期设计的。

这是红包生成数量的状态变化图
生成红包

非常的稳定。

这是客户端每秒获取的摇红包状态
获取红包

可以发现3万QPS区间,客户端每秒获取的红包数基本在200左右,在6万QPS的时候,以及出现剧烈的抖动,不能保证在200这个数值了。我觉得主要是6万QPS时候,网络的抖动加剧了,造成了红包数目也在抖动。

最后是golang 自带的pprof 信息,其中有gc 时间超过了10ms, 考虑到这是一个7年前的硬件,而且非独占模式,所以还是可以接受。
pprof

总结:

按照设计目标,我们模拟和设计了一个支持100万用户,并且每秒至少可以支持3万QPS,最多6万QPS的系统,简单模拟了微信的摇红包和发红包的过程。可以说达到了预期的目的。
如果600台主机每台主机可以支持6万QPS,只需要7分钟就可以完成 100亿次摇红包请求。

虽然这个原型简单地完成了预设的业务,但是它和真正的服务会有哪些差别呢?我罗列了一下

区别 真正服务 本次模拟
业务复杂 更复杂 非常简单
协议 Protobuf 以及加密 简单的协议
支付 复杂
日志 复杂
性能 更高
用户分布 用户id分散在不同服务器,需要hash以后统一, 复杂。 用户id 连续,很多优化使代码简单 非常高效
安全控制 复杂
热更新及版本控制 复杂
监控 细致 简单

Refers:

全栈必备:网络编程基础

我们是幸运的,因为我们拥有网络。网络是一个神奇的东西,它改变了你和我的生活方式,改变了整个世界。 然而,网络的无标度和小世界特性使得它又是复杂的,无所不在,无所不能,以致于我们无法区分甚至无法描述。

对于一个码农而言,了解网络的基础知识可能还是从了解定义开始,认识OSI的七层协议模型,深入Socket内部,进而熟练地进行网络编程。

关于网络

关于网络,在词典中的定义是这样的:

在电的系统中,由若干元件组成的用来使电信号按一定要求传输的电路或这种电路的部分,叫网络。

作为一名从事过TMN开发的通信专业毕业生,固执地认为网络是从通信系统中诞生的。通信是人与人之间通过某种媒介进行的信息交流与传递。传统的通信网络(即电话网络)是由传输、交换和终端三大部分组成,通信网络是指将各个孤立的设备进行物理连接,实现信息交换的链路,从而达到资源共享和通信的目的。通信网络可以从覆盖范围,拓扑结构,交换方式等诸多视角进行分类…… 满满的回忆,还是留在书架上吧。

网络的概念外延被不断的放大着,抽象的思维能力是人们创新乃至创造的根源。网络用来表示诸多对象及其相互联系,数学上的图,物理学上的模型,交通网络,人际网络,城市网络等等,总之,网络被总结成从同类问题中抽象出来用数学中的图论科学来表达并研究的一种模型。

很多伙伴认为,了解这些之后呢,然并卵。我们关心的只是计算机网络,算机网络是用通信线路和设备将分布在不同地点的多台计算机系统互相连接起来,按照网络协议,分享软硬件功能,最终实现资源共享的系统。特别的,我们谈到的网络只是互联网——Internet,或者移动互联网,需要的是写互连网应用程序。但是,一位工作了五六年的编程高手曾对我说,现在终于了解到基础知识有多重要,技术在不断演进,而相对不变的就是那些原理和编程模型了。

老码农深以为然,编程实践就是从具体到抽象,再到具体,循环往复,螺旋式上升的过程。了解前世今生,只是为了可能触摸到“势”。基础越扎实,建筑就会越有想象的空间。 对于网络编程的基础,大概要从OSI的七层协议模型开始了。

七层模型

七层模型(OSI,Open System Interconnection参考模型),是参考是国际标准化组织制定的一个用于计算机或通信系统间互联的标准体系。它是一个七层抽象的模型,不仅包括一系列抽象的术语和概念,也包括具体的协议。 经典的描述如下:

这里写图片描述

简述每一层的含义:

  1. 物理层(Physical Layer):建立、维护、断开物理连接。
  2. 数据链路层 (Link):逻辑连接、进行硬件地址寻址、差错校验等。
  3. 网络层 (Network):进行逻辑寻址,实现不同网络之间的路径选择。
  4. 传输层 (Transport):定义传输数据的协议端口号,及流控和差错校验。
  5. 会话层(Session Layer):建立、管理、终止会话。
  6. 表示层(Presentation Layer):数据的表示、安全、压缩。
  7. 应用层 (Application):网络服务与最终用户的一个接口

每一层利用下一层提供的服务与对等层通信,每一层使用自己的协议。了解了这些,然并卵。但是,这一模型确实是绝大多数网络编程的基础,作为抽象类存在的,而TCP/IP协议栈只是这一模型的一个具体实现。

TCP/IP 协议模型

TCP/IP是Internet的基础,是一组协议的代名词,包括许多协议,组成了TCP/IP协议栈。TCP/IP 有四层模型和五层模型之说,区别在于数据链路层是否作为独立的一层存在。个人倾向于5层模型,这样2层和3层的交换设备更容易弄明白。当谈到网络的2层或3层交换机的时候,就知道指的是那些协议。

这里写图片描述

数据是如何传递呢?这就要了解网络层和传输层的协议,我们熟知的IP包结构是这样的:
这里写图片描述
IP协议和IP地址是两个不同的概念,这里没有涉及IPV6的。不关注网络安全的话,对这些结构不必耳熟能详的。传输层使用这样的数据包进行传输,传输层又分为面向连接的可靠传输TCP和数据报UDP。TCP的包结构:
这里写图片描述
TCP 连接建立的三次握手肯定是必知必会,在系统调优的时候,内核中关于网络的相关参数与这个图息息相关。UDP是一种无连接的传输层协议,提供的是简单不可靠的信息传输。协议结构相对简单,包括源和目标的端口号,长度以及校验和。基于TCP和UDP的数据封装及解析示例如下:
这里写图片描述

还是然并卵么?一个数据包的大小了解了,会发现什么?PayLoad到底是多少?在设计协议通信的时候,这些都为我们提供了粒度定义的依据。进一步,通过一个例子看看吧。

模型解读示例

FTP是一个比较好的例子。为了方便起见,假设两条计算机分别是A 和 B,将使用FTP 将A上的一个文件X传输到B上。

首先,计算机A和B之间要有物理层的连接,可以是有线比如同轴电缆或者双绞线通过RJ-45的电路接口连接,也可以是无线连接例如WIFI。先简化一下,考虑局域网,暂不讨论路由器和交换机以及WIFI热点。这些物理层的连接建立了比特流的原始传输通路。

接下来,数据链路层登场,建立两台计算机的数据链路。如果A和B所在的网络上同时连接着计算机C,D,E等等,A和B之间如何建立的数据链路呢?这一过程就是物理寻址,A要在众多的物理连接中找到B,依赖的是计算机的物理地址即MAC地址,对就是网卡上的MAC地址。以太网采用CSMA/CD方式来传输数据,数据在以太网的局域网中都是以广播方式传输的,整个局域网中的所有节点都会收到该帧,只有目标MAC地址与自己的MAC地址相同的帧才会被接收。A通过差错控制和接入控制找到了B的网卡,建立可靠的数据通路。

那IP地址呢? 数据链路建立起来了,还需要IP地址么?我们FTP 命令中制定的是IP地址而不是MAC地址呀?IP地址是逻辑地址,包括网络地址和主机地址。如果A和B在不同的局域网中,中间有着多个路由器,A需要对B进行逻辑寻址才可以的。物理地址用于底层的硬件的通信,逻辑地址用于上层的协议间的通信。在以太网中:逻辑地址就是IP地址,物理地址就是MAC 地址。在使用中,两种地址是用一定的算法将他们两个联系起来的。所以,IP是用来在网络上选择路由的,在FTP的命令中,IP中的原地址就是A的IP地址,目标地址就是B的IP地址。这应该就是网络层,负责将分组数据从源端传输到目的端。

A向B传输一个文件时,如果文件中有部分数据丢失,就可能会造成在B上无法正常阅读或使用。所以需要一个可靠的连接,能够确保传输过程的完整性,这就是传输层的TCP协议,FTP就是建立在TCP之上的。TCP的三次握手确定了双方数据包的序号、最大接受数据的大小(window)以及MSS(Maximum Segment Size)。TCP利用IP完成寻址,TCP中的提供了端口号,FTP中目的端口号一般是21。传输层的端口号对应主机进程,指本地主机与远程主机正在进行的会话。

会话层用来建立、维护、管理应用程序之间的会话,主要功能是对话控制和同步,编程中所涉及的session是会话层的具体体现。表示层完成数据的解编码,加解密,压缩解压缩等,例如FTP中bin命令,代表了二进制传输,即所传输层数据的格式。 HTTP协议里body中的Json,XML等都可以认为是表示层。应用层就是具体应用的本身了,FTP中的PUT,GET等命令都是应用的具体功能特性。

简单地,物理层到电缆连接,数据链路层到网卡,网络层路由到主机,传输层到端口,会话层维持会话,表示层表达数据格式,应用层就是具体FTP中的各种命令功能了。

Socket

了解了7层模型就可以编程了么,拿起编程语言就可以耍了么?刚开始上手尝试还是可以的,如果要进一步,老码农觉得还是看看底层实现的好,因为一切归根到底都会归结为系统调用。到了操作系统层面如何看网络呢?Socket登场了。

在Linux世界,“一切皆文件”,操作系统把网络读写作为IO操作,就像读写文件那样,对外提供出来的编程接口就是Socket。所以,socket(套接字)是通信的基石,是支持TCP/IP协议网络通信的基本操作单元。socket实质上提供了进程通信的端点。进程通信之前,双方首先必须各自创建一个端点,否则是没有办法建立联系并相互通信的。一个完整的socket有一个本地唯一的socket号,这是由操作系统分配的。

从设计模式的角度看, Socket其实是一个外观模式,它把复杂的TCP/IP协议栈隐藏在Socket接口后面,对用户来说,一组简单的Socket接口就是全部。当应用程序创建一个socket时,操作系统就返回一个整数作为描述符(descriptor)来标识这个套接字。然后,应用程序以该描述符为传递参数,通过调用函数来完成某种操作(例如通过网络传送数据或接收输入的数据)。以TCP 为例,典型的Socket 使用如下:
这里写图片描述

在许多操作系统中,Socket描述符和其他I/O描述符是集成在一起的,操作系统把socket描述符实现为一个指针数组,这些指针指向内部数据结构。进一步看,操作系统为每个运行的进程维护一张单独的文件描述符表。当进程打开一个文件时,系统把一个指向此文件内部数据结构的指针写入文件描述符表,并把该表的索引值返回给调用者 。

既然Socket和操作系统的IO操作相关,那么各操作系统IO实现上的差异会导致Socket编程上的些许不同。看看我Mac上的Socket.so 会发现和CentOS上的还是些不同的。
这里写图片描述

进程进行Socket操作时,也有着多种处理方式,如阻塞式IO,非阻塞式IO,多路复用(select/poll/epoll),AIO等等。

多路复用往往在提升性能方面有着重要的作用。select系统调用的功能是对多个文件描述符进行监视,当有文件描述符的文件读写操作完成以及发生异常或者超时,该调用会返回这些文件描述符。select 需要遍历所有的文件描述符,就遍历操作而言,复杂度是 O(N)。

epoll相关系统调用是在Linux 2.5 后的某个版本开始引入的。该系统调用针对传统的select/poll不足,设计上作了很大的改动。select/poll 的缺点在于:

  1. 每次调用时要重复地从用户模式读入参数,并重复地扫描文件描述符。
  2. 每次在调用开始时,要把当前进程放入各个文件描述符的等待队列。在调用结束后,又把进程从各个等待队列中删除。

epoll 是把 select/poll 单个的操作拆分为 1 个 epoll_create,多个 epoll_ctrl和一个 wait。此外,操作系统内核针对 epoll 操作添加了一个文件系统,每一个或者多个要监视的文件描述符都有一个对应的inode 节点,主要信息保存在 eventpoll 结构中。而被监视的文件的重要信息则保存在 epitem 结构中,是一对多的关系。由于在执行 epoll_create 和 epoll_ctrl 时,已经把用户模式的信息保存到内核了, 所以之后即便反复地调用 epoll_wait,也不会重复地拷贝参数,不会重复扫描文件描述符,也不反复地把当前进程放入/拿出等待队列。

所以,当前主流的Server侧Socket实现大都采用了epoll的方式,例如Nginx, 在配置文件可以显式地看到 use epoll

网络编程

了解了7层协议模型和操作系统层面的Socket实现,可以方便我们理解网络编程。

在系统架构的时候,有重要的一环就是拓扑架构,这里涉及了网络等基础设施,那么7层协议下四层就会有助于我们对业务系统网络结构的观察和判断。在系统设计的时候,往往采用面向接口的设计,而接口也往往是基于HTTP协议的Restful API。 那接口的粒度就可以将data segment作为一个约束了,同时可以关注到移动互联网中的弱网环境。

不同的编程语言,有着不同的框架和库,真正的编写网络程序代码并不复杂,例如,用Erlang 中 gen_tcp 用于编写一个简单的Echo服务器:

然而,写出漂亮的服务器程序仍然是一件非常吃功夫的事情,例如,个人非常喜欢的python Tornado 代码, 在ioloop.py 中有对多路复用的选择:

在HTTPServer.py 中同样继承了TCPServer,进而实现了HTTP协议,代码片段如下:

或许,老码农说的都是错的,了解了所谓的网络基础,也不一定写出漂亮的代码,不了解所谓的网络基础,也不一定写不出漂亮的代码,全当他自言自语吧。

from:http://blog.jobbole.com/110041/

分布式系统中唯一 ID 的生成方法

本文主要介绍在一个分布式系统中, 怎么样生成全局唯一的 ID

一, 问题描述

在分布式系统存在多个 Shard 的场景中, 同时在各个 Shard 插入数据时, 怎么给这些数据生成全局的 unique ID?

在单机系统中 (例如一个 MySQL 实例), unique ID 的生成是非常简单的, 直接利用 MySQL 自带的自增 ID 功能就可以实现.

但在一个存在多个 Shards 的分布式系统 (例如多个 MySQL 实例组成一个集群, 在这个集群中插入数据), 这个问题会变得复杂, 所生成的全局的 unique ID 要满足以下需求:

  1. 保证生成的 ID 全局唯一
  2. 今后数据在多个 Shards 之间迁移不会受到 ID 生成方式的限制
  3. 生成的 ID 中最好能带上时间信息, 例如 ID 的前 k 位是 Timestamp, 这样能够直接通过对 ID 的前 k 位的排序来对数据按时间排序
  4. 生成的 ID 最好不大于 64 bits
  5. 生成 ID 的速度有要求. 例如, 在一个高吞吐量的场景中, 需要每秒生成几万个 ID (Twitter 最新的峰值到达了 143,199 Tweets/s, 也就是 10万+/秒)
  6. 整个服务最好没有单点

如果没有上面这些限制, 问题会相对简单, 例如:

  1. 直接利用 UUID.randomUUID() 接口来生成 unique ID (http://www.ietf.org/rfc/rfc4122.txt). 但这个方案生成的 ID 有 128 bits, 另外, 生成的 ID 中也没有带 Timestamp
  2. 利用一个中心服务器来统一生成 unique ID. 但这种方案可能存在单点问题; 另外, 要支持高吞吐率的系统, 这个方案还要做很多改进工作 (例如, 每次从中心服务器批量获取一批 IDs, 提升 ID 产生的吞吐率)
  3. Flickr 的做法 (http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/). 但他这个方案 ID 中没有带 Timestamp, 生成的 ID 不能按时间排序

在要满足前面 6 点要求的场景中, 怎么来生成全局 unique ID 呢?

Twitter 的 Snowflake 是一种比较好的做法. 下面主要介绍 Twitter Snowflake, 以及它的变种

二, Twitter Snowflake

https://github.com/twitter/snowflake

Snowflake 生成的 unique ID 的组成 (由高位到低位):

  • 41 bits: Timestamp (毫秒级)
  • 10 bits: 节点 ID (datacenter ID 5 bits + worker ID 5 bits)
  • 12 bits: sequence number

一共 63 bits (最高位是 0)

unique ID 生成过程:

  • 10 bits 的机器号, 在 ID 分配 Worker 启动的时候, 从一个 Zookeeper 集群获取 (保证所有的 Worker 不会有重复的机器号)
  • 41 bits 的 Timestamp: 每次要生成一个新 ID 的时候, 都会获取一下当前的 Timestamp, 然后分两种情况生成 sequence number:
  • 如果当前的 Timestamp 和前一个已生成 ID 的 Timestamp 相同 (在同一毫秒中), 就用前一个 ID 的 sequence number + 1 作为新的 sequence number (12 bits); 如果本毫秒内的所有 ID 用完, 等到下一毫秒继续 (这个等待过程中, 不能分配出新的 ID)
  • 如果当前的 Timestamp 比前一个 ID 的 Timestamp 大, 随机生成一个初始 sequence number (12 bits) 作为本毫秒内的第一个 sequence number

整个过程中, 只是在 Worker 启动的时候会对外部有依赖 (需要从 Zookeeper 获取 Worker 号), 之后就可以独立工作了, 做到了去中心化.

异常情况讨论:

  • 在获取当前 Timestamp 时, 如果获取到的时间戳比前一个已生成 ID 的 Timestamp 还要小怎么办? Snowflake 的做法是继续获取当前机器的时间, 直到获取到更大的 Timestamp 才能继续工作 (在这个等待过程中, 不能分配出新的 ID)

从这个异常情况可以看出, 如果 Snowflake 所运行的那些机器时钟有大的偏差时, 整个 Snowflake 系统不能正常工作 (偏差得越多, 分配新 ID 时等待的时间越久)

从 Snowflake 的官方文档 (https://github.com/twitter/snowflake/#system-clock-dependency) 中也可以看到, 它明确要求 “You should use NTP to keep your system clock accurate”. 而且最好把 NTP 配置成不会向后调整的模式. 也就是说, NTP 纠正时间时, 不会向后回拨机器时钟.

三, Snowflake 的其他变种

Snowflake 有一些变种, 各个应用结合自己的实际场景对 Snowflake 做了一些改动. 这里主要介绍 3 种.

1. Boundary flake

http://boundary.com/blog/2012/01/12/flake-a-decentralized-k-ordered-unique-id-generator-in-erlang/

变化:

  • ID 长度扩展到 128 bits:
  • 最高 64 bits 时间戳;
  • 然后是 48 bits 的 Worker 号 (和 Mac 地址一样长);
  • 最后是 16 bits 的 Seq Number
  • 由于它用 48 bits 作为 Worker ID, 和 Mac 地址的长度一样, 这样启动时不需要和 Zookeeper 通讯获取 Worker ID. 做到了完全的去中心化
  • 基于 Erlang

它这样做的目的是用更多的 bits 实现更小的冲突概率, 这样就支持更多的 Worker 同时工作. 同时, 每毫秒能分配出更多的 ID

2. Simpleflake

http://engineering.custommade.com/simpleflake-distributed-id-generation-for-the-lazy/

Simpleflake 的思路是取消 Worker 号, 保留 41 bits 的 Timestamp, 同时把 sequence number 扩展到 22 bits;

Simpleflake 的特点:

  • sequence number 完全靠随机产生 (这样也导致了生成的 ID 可能出现重复)
  • 没有 Worker 号, 也就不需要和 Zookeeper 通讯, 实现了完全去中心化
  • Timestamp 保持和 Snowflake 一致, 今后可以无缝升级到 Snowflake

Simpleflake 的问题就是 sequence number 完全随机生成, 会导致生成的 ID 重复的可能. 这个生成 ID 重复的概率随着每秒生成的 ID 数的增长而增长.

所以, Simpleflake 的限制就是每秒生成的 ID 不能太多 (最好小于 100次/秒, 如果大于 100次/秒的场景, Simpleflake 就不适用了, 建议切换回 Snowflake).

3. instagram 的做法

先简单介绍一下 instagram 的分布式存储方案:

  • 先把每个 Table 划分为多个逻辑分片 (logic Shard), 逻辑分片的数量可以很大, 例如 2000 个逻辑分片
  • 然后制定一个规则, 规定每个逻辑分片被存储到哪个数据库实例上面; 数据库实例不需要很多. 例如, 对有 2 个 PostgreSQL 实例的系统 (instagram 使用 PostgreSQL); 可以使用奇数逻辑分片存放到第一个数据库实例, 偶数逻辑分片存放到第二个数据库实例的规则
  • 每个 Table 指定一个字段作为分片字段 (例如, 对用户表, 可以指定 uid 作为分片字段)
  • 插入一个新的数据时, 先根据分片字段的值, 决定数据被分配到哪个逻辑分片 (logic Shard)
  • 然后再根据 logic Shard 和 PostgreSQL 实例的对应关系, 确定这条数据应该被存放到哪台 PostgreSQL 实例上

instagram unique ID 的组成:

  • 41 bits: Timestamp (毫秒)
  • 13 bits: 每个 logic Shard 的代号 (最大支持 8 x 1024 个 logic Shards)
  • 10 bits: sequence number; 每个 Shard 每毫秒最多可以生成 1024 个 ID

生成 unique ID 时, 41 bits 的 Timestamp 和 Snowflake 类似, 这里就不细说了.

主要介绍一下 13 bits 的 logic Shard 代号 和 10 bits 的 sequence number 怎么生成.

logic Shard 代号:

  • 假设插入一条新的用户记录, 插入时, 根据 uid 来判断这条记录应该被插入到哪个 logic Shard 中.
  • 假设当前要插入的记录会被插入到第 1341 号 logic Shard 中 (假设当前的这个 Table 一共有 2000 个 logic Shard)
  • 新生成 ID 的 13 bits 段要填的就是 1341 这个数字

sequence number 利用 PostgreSQL 每个 Table 上的 auto-increment sequence 来生成:

  • 如果当前表上已经有 5000 条记录, 那么这个表的下一个 auto-increment sequence 就是 5001 (直接调用 PL/PGSQL 提供的方法可以获取到)
  • 然后把 这个 5001 对 1024 取模就得到了 10 bits 的 sequence number

instagram 这个方案的优势在于:

  • 利用 logic Shard 号来替换 Snowflake 使用的 Worker 号, 就不需要到中心节点获取 Worker 号了. 做到了完全去中心化
  • 另外一个附带的好处就是, 可以通过 ID 直接知道这条记录被存放在哪个 logic Shard 上

同时, 今后做数据迁移的时候, 也是按 logic Shard 为单位做数据迁移的, 所以这种做法也不会影响到今后的数据迁移

from:http://blog.jobbole.com/110064/

瞬时高并发(秒杀/活动)Redis方案

1,Redis
  • 丰富的数据结构(Data Structures)
    • 字符串(String)
      • Redis字符串能包含 任意类型的数据
      • 一个字符串类型的值最多能存储 512M字节的内容
      • 利用 INCR命令簇INCR, DECR, INCRBY)来把字符串当作 原子计数器使用
      • 使用 APPEND命令在字符串后添加内容
    • 列表(List)
      • Redis列表是简单的字符串列表,按照插入顺序排序
      • 你可以添加一个元素到列表的 头部(左边:LPUSH)或者 尾部(右边:RPUSH)
      • 一个列表最多可以包含232-1个元素(4294967295,每个表超过 40亿个元素
      • 在社交网络中建立一个时间线模型,使用 LPUSH去添加 新的元素用户时间线中,使用 LRANGE去检索一些 最近插入的条目
      • 你可以同时使用 LPUSHLTRIM去创建一个 永远不会超过指定元素数目列表并同时记住 最后的N个元素
      • 列表可以用来当作 消息传递基元(primitive),例如,众所周知的用来创建后台任务的Resque Ruby库
    • 集合(Set)
      • Redis集合是一个 无序的, 不允许相同成员存在的字符串合集( Uniq操作,获取某段时间所有数据 排重值
      • 支持一些服务端的命令从现有的集合出发去进行 集合运算,如合并( 并集:union),求交( 交集:intersection), 差集, 找出不同元素的操作(共同好友、二度好友)
      • 用集合跟踪一个独特的事。想要知道所有访问某个博客文章的独立IP?只要每次都用SADD来处理一个页面访问。那么你可以肯定重复的IP是不会插入的( 利用 唯一性,可以 统计访问网站的所有独立IP
      • Redis集合能很好的表示 关系。你可以创建一个tagging系统,然后用集合来代表单个tag。接下来你可以用SADD命令把所有拥有tag的对象的所有ID添加进集合,这样来表示这个特定的tag。如果你想要同时有3个不同tag的所有对象的所有ID,那么你需要使用 SINTER
      • 使用 SPOP或者 SRANDMEMBER命令 随机地获取元素
    • 哈希(Hashes)
      • Redis Hashes是字符串字段和字符串值之间的映射
      • 尽管Hashes主要用来表示对象,但它们也能够 存储许多元素
    • 有序集合(Sorted Sets)
      • Redis有序集合和Redis集合类似,是 不包含相同字符串的合集
      • 每个有序集合的成员都 关联着一个评分,这个评分用于把有序集合中的成员按最低分到最高分排列( 排行榜应用,取TOP N操作
      • 使用有序集合,你可以非常快地(O(log(N)))完成添加,删除和更新元素的操作
      • 元素是在插入时就排好序的,所以很快地通过 评分(score)或者 位次(position)获得一个 范围的元素(需要 精准设定过期时间的应用)
      • 轻易地访问任何你需要的东西:  有序的元素快速的存在性测试快速访问集合中间元素
      • 在一个 巨型在线游戏中建立一个 排行榜,每当有新的记录产生时,使用 ZADD 来更新它。你可以用 ZRANGE轻松地获取 排名靠前的用户, 你也可以提供一个用户名,然后用 ZRANK获取他在 排行榜中的名次。 同时使用 ZRANKZRANGE你可以获得与指定用户有相同分数的用户名单。 所有这些操作都非常迅速
      • 有序集合通常用来 索引存储在Redis中的数据。 例如:如果你有很多的hash来表示用户,那么你可以使用一个有序集合,这个集合的年龄字段用来当作评分,用户ID当作值。用 ZRANGEBYSCORE可以简单快速地检索到 给定年龄段的所有用户
  • 复制(Replication, Redis复制很简单易用,它通过配置允许slave Redis Servers或者Master Servers的复制品)
    • 一个Master可以有 多个Slaves
    • Slaves能 通过接口其他slave的链接,除了可以接受同一个master下面slaves的链接以外,还可以接受同一个结构图中的其他slaves的链接
    • redis 复制是在 master段非阻塞的,这就意味着master在同一个或多个slave端 执行同步的时候还可以 接受查询
    • 复制slave端也是非阻塞的,假设你在redis.conf中配置redis这个功能,当slave在执行的新的同步时,它仍可以用旧的数据信息来提供查询,否则,你可以配置当redis slaves去master失去联系是,slave会给发送一个客户端错误
    • 为了有多个slaves可以做只读查询, 复制可以重复2次,甚至多次,具有 可扩展性(例如:slaves对话与重复的排序操作,有多份数据冗余就相对简单了)
    • 他可以利用 复制去避免在master端保存数据,只要对master端redis.conf进行配置,就可以避免保存(所有的保存操作),然后通过slave的链接,来实时的保存在slave端
  • LRU过期处理(Eviction)
    • EVAL 和 EVALSHA 命令是从 Redis 2.6.0 版本开始的,使用内置的 Lua 解释器,可以对 Lua 脚本进行求值
    • Redis 使用 单个 Lua 解释器去运行所有脚本,并且, Redis 也保证脚本会以 原子性(atomic)的方式执行:  当某个脚本正在运行的时候,不会有其他脚本或 Redis 命令被执行。 这和使用 MULTI / EXEC  包围的事务很类似。 在其他别的客户端看来,脚本的效果(effect)要么是不可见的(not visible),要么就是已完成的(already completed)
    • LRU过期处理(Eviction)
      • Redis允许为每一个key设置不同的 过期时间,当它们到期时将自动从服务器上删除(EXPIRE)
  • 事务
    • MULTI 、 EXEC 、 DISCARD 和  WATCH 是 Redis  事务的基础
    • 事务是一个 单独的隔离操作:事务中的所有 命令都会 序列化、按顺序地执行。事务在 执行的过程中不会被其他客户端发送来的命令请求所打断
    • 事务中的命令要么全部被执行,要么全部都不执行EXEC 命令负责触发并执行事务中的所有命令
    • Redis 的 Transactions 提供的并 不是严格的 ACID 的事务
    • Transactions 还是提供了基本的 命令打包执行的功能: 可以保证一连串的命令是顺序在一起执行的,中间有会有其它客户端命令插进来执行
    • Redis 还提供了一个  Watch 功能,你可以 对一个 key 进行 Watch,然后再 执行 Transactions,在这过程中,如果这个  Watched 的值进行了修改,那么这个  Transactions 会发现并拒绝执行
  • 数据持久化
    • RDB
      • 特点
        • RDB持久化方式能够在 指定的时间间隔能对你的 数据进行快照存储
      • 优点
        • RDB是一个非常 紧凑的文件,它保存了 某个时间点得数据集,非常 适用于数据集的备份
        • RDB是一个紧凑的单一文件, 非常 适用于灾难恢复
        • RDB在保存RDB文件时父进程唯一需要做的就是 fork出一个子进程,接下来的 工作全部由 子进程来做,父进程不需要再做其他IO操作,所以RDB持久化方式可以 最大化redis的性能
        • 与AOF相比,在 恢复大的数据集的时候, RDB方式会更快一些
      • 缺点
        • 如果你希望在 redis意外停止工作(例如电源中断)的情况下 丢失的数据最少的话,那么 RDB不适合,Redis要完整的 保存整个数据集是一个比较 繁重的工作
        • RDB 需要经常fork子进程来保存数据集到硬盘上,当 数据集比较大的时候, fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒, AOF也需要fork,但是你可以 调节重写日志文件的频率来提高数据集的耐久度
    • AOF
      • 特点
        • AOF持久化方式记录 每次对服务器写的操作
        • redis重启的时候会 优先载入AOF文件恢复原始的数据,因为在通常情况下 AOF文件保存的数据集要比 RDB文件保存的 数据集要完整
      • 优点
        • 使用AOF 会让你的Redis 更加耐久: 你可以使用不同的 fsync策略无fsync,每秒fsync,每次写的时候fsync
        • AOF文件是一个只 进行追加的日志文件,所以不需要写入seek
        • Redis 可以在 AOF 文件体积 变得过大时, 自动地在后台对  AOF 进行重写
        • AOF 文件有序地保存了对数据库执行的所有写入操作, 这些写入操作以 Redis 协议的格式保存, 因此  AOF 文件的内容非常 容易被人读懂, 对文件进行 分析(parse)也很轻松。  导出(export) AOF 文件也非常简单
      • 缺点
        • 对于 相同的数据集来说, AOF 文件的体积通常要 大于 RDB 文件的体积
        • 根据所使用的  fsync 策略, AOF 的速度可能会 慢于 RDB
    • 选择
      • 同时使用 两种持久化功能
  • 分布式
    • Redis Cluster (Redis 3版本)
    • Keepalived
      • Master挂了后VIP漂移到SlaveSlave 上 keepalived 通知redis 执行:slaveof no one ,开始提供业务
      • Master起来后VIP 地址不变Masterkeepalived 通知redis 执行slaveof slave IP host ,开始 作为从同步数据
      • 依次类推
    • Twemproxy
      • 快、轻量级、减少后端Cache Server连接数、易配置、支持ketama、modula、random、常用hash 分片算法
      • 对于客户端而言,r edis集群是透明的,客户端简单,遍于动态扩容
      • Proxy为 单点、处理一致性hash时,集群节点 可用性检测不存在脑裂问题
      • 高性能,CPU密集型,而 redis节点集群多CPU资源冗余,可部署在redis节点集群上,不需要额外设备
  • 高可用(HA)
    • Redis Sentinel(redis自带的集群管理工具 )
      • 监控(Monitoring): Redis Sentinel实时监控主服务器和从服务器运行状态
      • 提醒(Notification):当被监控的某个 Redis 服务器出现问题时, Redis Sentinel 可以向系统管理员发送通知, 也可以通过 API 向其他程序发送通知
      • 自动故障转移(Automatic failover): 当一个主服务器不能正常工作时,Redis Sentinel 可以将一个从服务器升级为主服务器, 并对其他从服务器进行配置,让它们使用新的主服务器。当应用程序连接到 Redis 服务器时, Redis Sentinel会告之新的主服务器地址和端口
    • 单M-S结构
      • 单M-S结构特点是在Master服务器中配置 Master Redis(Redis-1M)和 Master Sentinel(Sentinel-1M)
      • Slave服务器中配置 Slave Redis(Redis-1S)和 Slave Sentinel(Sentinel-1S)
      • 其中  Master Redis可以提供 读写服务,但是 Slave Redis只能提供 只读服务。因此,在业务压力比较大的情况下,可以选择将只读业务放在Slave Redis中进行
    • 双M-S结构
      • 双M-S结构的特点是在 每台服务器上配置一个 Master Redis,同时部署一个 Slave Redis。由两个 Redis Sentinel同时对 4个Redis进行监控两个Master Redis可以同时对应用程序提供 读写服务,即便其中一个服务器出现故障,另一个服务器也可以同时运行两个Master Redis提供读写服务
      • 缺点是 两个Master redis之间无法实现数据共享,不适合存在大量用户数据关联的应用使用
    • 单M-S结构和双M-S结构比较
      • 单M-S结构适用于 不同用户数据存在关联,但 应用可以实现读写分离的业务模式Master主要提供写操作,Slave主要提供读操作,充分利用硬件资源
      • 双(多)M-S结构适用于 用户间不存在或者存在较少的数据关联的业务模式读写效率是单M-S的两(多)倍,但 要求故障时单台服务器能够承担两个Mater Redis的资源需求
  • 发布/订阅(Pub/Sub)
  • 监控:Redis-Monitor
    • 历史redis运行查询: CPU、内存、命中率、请求量、主从切换
    • 实时监控曲线
2,数据类型Redis使用场景
  • String
    •   计数器应用
  • List
    • 最新N个数据的操作
    • 消息队列
    • 删除过滤
    • 实时分析正在发生的情况,用于 数据统计防止垃圾邮件(结合Set)
  • Set
    • Uniqe操作,获取某段时间所有数据 排重值
    • 实时系统,反垃圾系统
    • 共同好友、二度好友
    • 利用 唯一性,可以 统计访问网站的所有 独立 IP
    • 好友推荐的时候,根据 tag  求交集,大于某个 threshold 就可以推荐
  • Hashes
    • 存储、读取、修改用户属性
  • Sorted Set
    • 排行榜应用,取 TOP N操作
    • 需要 精准设定过期时间的应用(时间戳作为Score)
    • 带有 权重的元素,比如一个游戏的用户得分排行榜
    • 过期项目处理,按照时间排序
3,Redis解决秒杀/抢红包等高并发事务活动
  • 秒杀开始前30分钟把秒杀库存从数据库同步到Redis Sorted Set
  • 用户秒杀 库存放入秒杀限制数长度的 Sorted Set
  • 秒杀到 指定秒杀数后, Sorted Set不在接受秒杀请求,并显示返回标识
  • 秒杀活动完全结束后, 同步Redis数据到数据库,秒杀正式结束