- 浏览: 501388 次
- 性别:
- 来自: 深圳
-
文章分类
- 全部博客 (185)
- job (15)
- linux/windows/unix/bash/shell (31)
- JAVA/J2EE/spring/hibernate/struts (30)
- VC/C++ (48)
- mysql/postgresql (6)
- php/jsp/asp/pear (1)
- FMS/flex/openlaszlo/red5/openmeetings (34)
- apache/tomcat/ftp/svn (6)
- xen/vm/Hadoop/cloudcompute (6)
- visual studio/eclipse/zendstudi/ant (8)
- others (1)
- windows异常处理 __try __except (1)
- (1)
- matlab (4)
- android (0)
最新评论
-
hongzhounlfd:
很透彻,很详细
依赖注入和控制反转 -
jefferyqjy:
谢谢~言简意赅~很明了!
依赖注入和控制反转 -
elderbrother:
太好了,谢谢
依赖注入和控制反转 -
east_zyd_zhao:
终于搞明白了
依赖注入和控制反转 -
Dremeng:
完美,一看就懂理解透彻
依赖注入和控制反转
微博平台首席架构师杨卫华演讲 新浪科技讯 11月16日下午消息,由新浪微博主办的中国首届微博开发者大会在北京举行,这是国内微博行业的首场技术盛宴。作为国内微博市场的绝对领军者,新浪微博将在此次大会上公布一系列针对开发者的扶持政策,以期与第三方开发者联手推动微博行业的整体发展。
媒体来源:新浪科技
以下为演讲实录:
大家下午好,在座的大部分都是技术开发者,技术开发者往往对微博这个产品非常关心。最晚的一次,是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣,就是一个明星他有300万粉丝,这个技术怎么来实现?今天在这里跟大家分享一下微博的底层机构,让大家对微博的底层技术有更好的了解。另外不管是做客户端、Web 1.0、Web 2.0、论坛、博客都要考虑架构的问题,架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构,分析一下架构里面哪些共性大家可以参考。
首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户,我们的基层架构也发展了3个大的版本。第一版就LAMP架构,优点是可以非常快的实现我们的系统。我们看一下技术特点,微博这个产品从架构上来分析,它需要解决的是发表和订阅的问题。我们第一版采用的是推消息模式,假如说我们一个明星用户他有10万个粉丝,那就是说用户发表一条微博的时候,我们把这个微博消息存成10万份,这样就是很简单了,第一版的架构实际上就是这两行字。第一版的技术细节,典型的LAMP架构,是使用MyISAM搜索引擎,它的优点就是速度非常快。
另外一个是MPSS,就是多个端口可以布置在同一服务器上。为什么使用MPSS?假如说我们做一个互联网应用,这个应用里面有三个单元,我们可以由2种部署方式。我们可以把三个单元分别部署在三台服务器上,另外一种部署模式就是这三个单元部署在每个服务器上都有。我推荐第2种方法。这个方法解决了两个问题,一个是负载均衡,因为每一个单元都有多个节点处理,另外一个是可以防止单点故障。如果我们按照模式1来做的话,任何一个节点有故障就会影响我们系统服务,如果模式二的话,任何一个结点发生故障我们的整体都不会受到影响的。
我们微博第一版上线之后,用户非常喜欢这个产品,用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象,尤其是明星用户他的粉丝多系统需要处理很长时间。另外系统在处理明星用户发表时系统繁忙可能会影响到其他的用户,因为其他的用户同一时间发表的话,也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式,这肯定是延迟的首要原因,我们要把这个问题解决掉。其次我们的用户越来越多,这个数据库表从一百万到一亿,数据规模不一样处理方式是有差别的。我们第一版单库单表的模式,当用户数量增多的时候,它不能满足就需要进行拆分。第二个是锁表的问题,我们考虑的是更改引擎。另外一个是发表过慢,我们考虑的是异步模式。
第二版我们进行了模块化,我们首先做了一个分层,最底层叫基础层,首先对数据做了拆分,图上最右边是发表做了异步模式。第二个服务层,我们把微博基础的单元设计成服务层一个一个模块,最大改进是对推模式进行了改进。首先看一下投递模式的优化,首先我们要思考推模式,如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝,我发一条微博的时候不需要推给一百个粉丝,因为可能有50个粉丝不会马上来看,这样同步推送给他们,相当于做无用功。我们把用户分成有效和无效之后,我们把他们做一下区分,比如说当天登陆过的人我们分成有效用户的话,只需要发送给当天登陆过的粉丝,这样压力马上就减轻了,另外投递的延迟也减小了。
我们再看数据的拆分,数据拆分有很多方式,很多互联网产品最常用的方法,比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的数据,所以我们考虑微博的数据我们按照时间拆分,比如说一个月放一张表,这样就解决了我们不同时间的维度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的uid,微博id是索引数据,140个字的内容是内容数据。假如我们分开的话,内容就简单的变成了一种key-value的方式,key-value是最容易扩展的一种数据。索引数据的拆分具有挑战,比如说一个用户发表了一千条微博,这一千条微博我们接口前端要分页访问,比如说用户需要访问第五页,那我们需要迅速定位到这个记录。
假如说我们把这个索引拆分成一个月一张表,我们记录上很难判断第五页在哪张表里,我们需要加载所有的索引表。如果这个地方不能拆分,那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法,就是索引上做了一个二次索引,把每个月记录的偏移记下来,就是一个月这个用户发表了多少条,ID是哪里,就是按照这些数据迅速把记录找出来。
异步处理,发表是一个非常繁重的操作,它要入库、统计索引、进入后台,如果我们要把所有的索引都做完用户需要前端等待很长的时间,如果有一个环节失败的话,用户得到的提示是发表失败,但是入库已经成功,这样会带来数据不一致问题。所以我们做了一个异步操作,就是发表成功我们就提示成功,然后在后台慢慢的消息队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ,我们去年做了一个对大规模部署非常有利的指令,就是statsqueue,适合大规模运维。
第二版我们做了这些改进之后,微博的用户和访问量并没有停止,还有很多新的问题出现。比如说系统问题,单点故障导致的雪崩,第二个是访问速度问题因为国内网络环境复杂,会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值,MySql复制延迟、慢查询,另外就是热门事件,比如说世界杯,可能会导致用户每秒发表的内容达到几千条。我们考虑如何改进,首先系统方面允许任意模块失败。另外静态内容,第一步我们用CDN来加速,另外数据的压力以及峰值,我们需要将数据、功能、部署尽可能的拆分,然后提前进行容量规划。
另一方面我们还有平台化的需求,去年11月我们就说要做开放平台,开放平台的需求是有差异的,Web系统它有用户行为才有请求,但是API系统特别是客户端的应用,只要用户一开机就会有请求,直到他关闭电脑这种请求一直会不间断的过来,另外用户行为很难预测。
系统规模在持续的增大,另外也有平台化的需求,我们新架构应该怎么做才能满足这些需要?我们看一下同行,比如说Google怎么样考虑这个问题的?Google首席科学家讲过一句话,就是一个大的复杂的系统,应该要分解成很多小的服务。比如说我们在Google.com执行一个搜索查询的话,实际上这个操作会调动内部一百多个服务。因此,我们第三版的考虑就是先有服务才有接口最后才有应用,我们才能把这个系统做大。
现在我们看一下第三版,首先我们把底层的东西分成基础服务,基础服务里面有分布式的存储,我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务,我们把微博常用的应用做成各种小的服务。然后我们还有应用服务,这个是专门考虑平台各种应用的需求。最上面我们有API,API就是新浪微博各种第三方应用都在上面跑。
平台服务和应用服务是分开的,这样实现了模块隔离,即使应用服务访问量过大的话,平台服务不会首先影响。另外我们把微博的引擎进行了改进,实现了一个分层关系。用户的关注关系,我们改成一个多惟度的索引结构,性能极大的提高。第四个层面就是计数器的改进,新版我们改成了基于偏移的思路,就是一个用户他原来读的一个ID比如说是10000,系统最系的ID是10002的话,我们很清楚他有两条未读。原来的版本是采用绝对计数的,这个用户有几条未读都是用一个存储结构的话,就容易产生一致性的问题,采用这种偏移的技术基本上不会出错。
另外基础服务DB冷热分离多维度拆分,在微博里面我们是按照时间拆分的,但是一个大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分,这个按照UID来拆分可能更简单。然后我们突出存储还做了一个去中心化,就是用户上传图片的速度会极大的提高,另外察看其他用户的图片速度也会极大的提高。另外是动态内容支持多IDC同时更新,这个是在国内比较新颖的。
下面给大家介绍一下新浪微博怎么样打造一个高性能架构。到目前为止有五千万用户使用新浪微博,最高发表3000条以上每秒,然后一个明星用户发表的话,会被几百万用户同时读到。这些问题的本质是我们架构需要考虑高访问量、海量数据的情况下三个问题。易于扩展、低延迟、高可用和异地分布。我们每天有数十亿次外部网页以及API接口的需求,我们知道微博的特点是用户请求是无法cache的。因此面对这个需求我们怎么样扩展?几点思路。第一我们的模块设计上要去状态,我们任意一个单元可以支持任意节点。另外是去中心化,避免单点及瓶颈。另外是可线性扩展。最后一个是减少模块。
我们要做一个高性能的系统,要具备一个低延迟、高实时性,微博要做到高实时性这是核心的价值,实时性的核心就是让数据离CPU最近,避免磁盘的
IO。我们看淘宝核心系统专家余锋说过的一句话“CPU访问L1就像从书桌拿一本书,L2是从书架拿一本书,L3是从客厅桌子上拿一本书,访问主存就像骑车去社区图书馆拿一书”。我们微博如果要做到非常实时的话,我们就需要把数据尽量离CPU节点最近。所以我们看一下cache设计里面怎么达到这个目标。首先INBOX,这个数据我们需要放再一个最快的地方,因为用户随时访问。OutBOX里面的最近发表就是L1cache,还有一个是中期的,这个因为访问少一点,它可以被踢。最后一部分内容体有三部分。L0是本地的,我们需要把一些经常访问的,比如说明星发表微博的内容体本地化,因为它被访问的概率非常大。然后L1里面存放着最近发表的,还有一个是中期的。我们通常用L2就可以了,L1我们可以理解成它就是一个RAM存储。
一个好的架构还需要举行高可用性。我们看一下业界的指标,S3是99.9%,EC2是99.5%,我们另外一个同行Facebook在这方面它是没有承诺的,就是接口可用写。微博平台目前承诺的是99.95%,就是说一天365天故障率应该小于9小时。这个怎么达到?第一我们要做容量规划,要做好监控以及入口的管理,就是说有些服务如果访问量过了的话,我们要有一个开关可以拦住他。我们通过这个图表可以清楚的看到,比如说我们要做L1的cache,我们剩余空间有多少,比如说80%,就说明这个数据有可能会丢失,有可能会对我们的系统造成影响。
另外一个层面就是接口监控,我们目前有Google维度的接口监控,包括访问错误失败率。然后要做架构,给大家一个很重要的经验分享,就是说监控的指标尽量量化。比如说他延迟30秒是小问题,如果是延迟10分钟我们就要立即采取措施了,就是所有可以量化的指标都要量化。
然后我们看监控怎么样更好的做?我们看亚马逊的VP说过的一句话,就是说监控系统确实特别好,可以立即告诉我们哪里有故障,但是有20%的概率我们人是会出错的。所以我们一个大型系统就应该要为自动化设计,就是说尽可能的将一些运作自动化。比如说发布安装、服务、启用、停止。我们再看另外一句,Google的工程师是怎么做的。他是这么做的,比如说第一周是处理线上的业务,这一周他处理了很多事情,处理了很多系统的情况,剩下几周时间没有别的工作,他只要把这一周碰到的情况用程序的方法来解决,下次再碰到这种情况很简单的一个按钮就可以处理了。我们目前也在向自动化这方面努力,就是我们的工具在持续增加。
另外一个异地分布,在国内网络环境下,比如说IDC灾难,机房检修甚至是机房掉电,我们也碰到过中国最好的机房也会掉电,所以要每个服务单元都能支持多机房部署。另外做多机房部署有一个好处,就是用户的访问速度会提高。多IDC分布静态内容就不说了,基本上大的互联网公司都会做,它非常成熟基本上没有什么问题,比如说图片等等的静态内容。动态内容的CDN分布是业内的难点,国内很少有公司能够做到非常成熟的多机房动态内容发布的成熟方案,它的核心就是分布式存储。一款理想的分布式存储产品它有哪些需求呢?首先它要支持海量规模、可扩展、高性能、低延迟、高可用。第二个是需要多机房分布,能够满足国内负责的网络环境,还要具备异地容灾能力。第三个就是要调用简单,具备丰富数据库特性。因此分布式存储需要解决一个多对多的数据复制。
如果要做复制无非是三种策略,第一个是Master/Slave,但是它也两个缺点,第一个是Master是中心化的,如果Master在北京那广州访问就非常慢。第二个缺点是有单点风险的,比如说Master在北京,能立即迁到广州吗?这样有个时间窗口的数据就丢失了,而且需要人工的干预,而且日常广州的用户访问北京的Master是有很大延迟问题的,所以一般来说要做的非常优秀是不会考虑第一种方案的。第二种就是Multi-Master方案,它需要应用避免冲突,就是我们不能多处改变。这个对于微博来说不会特别难,我们的用户通常只会再一个地方发表微博,用户不会同时在广州又在北京发表或者是修改自己的资料,这样的话我们应用上就已经避免了这种情况。第三个就是Paxos就是可以达到强一致写,就是一条数据如果成功肯定是多个机房都成功了,这个也显而易见就是延迟性非常大。因此总结一下Multi-Master是最成熟的策略,但是它现在没有成熟的产品,因为确实没有。
我们再来看微博的方案,所以我们自己实现了一个多机房同步的方案。就是我们前端应用将数据写到数据库,再通过一个消息代理,相当于通过我们自己开发的一个技术,将数据广播到多个机房。这个不但可以做到两个机房,而且可以做到三个、四个。具体的方式就是通过消息广播方式将数据多点分布,就是说我们的数据提交给一个代理,这个代理帮我们把这些数据同步到多个机房,那我们应用不需要关心这个数据是怎么样同步过去的。
用这种消息代理方式有什么好处呢?可以看一下Yahoo是怎么来做的?第一个是数据提供之后没有写到db之后是不会消失的,我只要把数据提交成功就可以了,不需要关心数据怎么到达机房。第二个特点YMB是一款消息代理的产品,但是它唯一神奇的地方是为广域网设计的,它可以把多机房应用归到内部,我们应用不需要关注这个问题。这个原理跟我们目前自己开发的技术相似。
然后我们再看一下目前即将推出的微博平台的新架构。我们知道API大部分的请求都为了获取最新的数据。API请求有一个特点,它大目前调用都是空返回的,比如说一款手机的客户端每隔一分钟它都要调用服务器一下,就是有没有新数据,大目前的调用都是空返回,就是说不管服务器有没有数据都要调用一次。这次询问到下一次询问中间,如果有新的数据来了,你是不会马上知道的。因此我们想API能不能改用推的方式,就是客户端不需要持续的调用,如果有新数据就会推过去。技术特点,显而易见低延迟,就是从发表到接受1秒内完成,实际上可能用不了1秒。然后服务端的连接就是高并发长连接服务,就是多点都连接在我们的服务器上,这个比传统的API要大很多。
我们看一下推送架构怎么从架构底层做到实时性的。从左上角的一条微博在我们系统发布之后,我们把它放在一个消息队列里面,然后会有一个消息队列的处理程序把它拿过来,处理以后放到db里面。假如说我们不做持久化,因为我们推送数据也不能丢失,我们就要写一个很复杂的程序,将数据异步去存,这样就会非常复杂,而且系统也会有不稳定的因素。从另外一个角度来说,我们做持久化也是做过测试的。我们推送整个流程可以做到100毫秒和200毫秒之间,就是说我们在这个时间能把数据推送出去。
我们再看一下内部细节,就是我们收到数据之后首先要经过最上面RECEIVER。然后推到我们的引擎里面,这个引擎会做两个事情,首先会把用户的关系拿过来,然后按照用户关系马上推送给他相应的粉丝。所以我们调用方已经在那儿等待了,我们需要有一个唤醒操作,就是说在接口这儿把它唤醒,然后把它发送过去。最后是一个高并发的长连服务器,就是一台服务器支持10万以上的并发连接。最右边中间有一个圆圈叫做Stream Buffer,我们需要Stream Buffer是要保存用户最近的数据。因为用户可能会有断线的,比如说他发送数据的时候断线半分钟,我们需要把这半分钟补给他。这就是我们的推送架构。
下面介绍一下平台安全部分。由于我们的接口是完全开放的,所以我们要防范很多恶意行为,有很多人担心我们接口是开放的,是不是有人通过这个接口发垃圾广告,或者是刷粉丝,我们技术架构怎么来防范这一点呢?这是我们的安全架构,做了三个层面的事情。最上面是我们有一个实时处理,比如说根据频度、内容的相似性来进行判断,判断发的是不是广告或者是垃圾内容。中间这个是一个日志处理器,我们会根据一些行为进行判断,比如说如果我们只是实时拦截的话,有些行为很难防止,我们做了个离线纠正的模块,比如说他潜伏的几个月开始发广告了,我们可以事后把这些人清除掉,以保证我们平台的健康。最后是通过监控的维度来保证内容的安全。目前内容安全的架构大概是541的体系,就是说我们的实时拦截可以做到50%的防止,离线分析大概可以做到40%的防止。
微博平台需要为用户提供安全及良好的体验应用,以及为开发者营造一个公平的环境,所以我们的接口需要清晰安全的规则。从一个APP调用我们的接口,需要几个阶层,需要划分不同的业务模块。第二个是安全层。第三个是权限层。这是我们平台安全的两个维度,一个接口安全,一个是内容安全。
我今天讲的是架构方面的问题,在座大部分是开发者,可能大家都在处理不同的架构问题,架构很多地方是相通的。我们需要做一个软件系统需要解决的本质问题是什么?微博第一版解决发布规模问题,第二版是解决数据规模的问题,第三版是解决服务化的问题。将复杂的问题简单化之后,我们才可以设计出一个容易扩展的大规模架构。我今天介绍就这么多,我们微博实际上是很需要各方面的技术人员,大家对我们的架构如果感兴趣的话、对我们的系统感兴趣的话,也希望各方面的技术人员参与我们微博的团队,随时可以给我微博上发私信。
媒体来源:新浪科技
以下为演讲实录:
大家下午好,在座的大部分都是技术开发者,技术开发者往往对微博这个产品非常关心。最晚的一次,是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣,就是一个明星他有300万粉丝,这个技术怎么来实现?今天在这里跟大家分享一下微博的底层机构,让大家对微博的底层技术有更好的了解。另外不管是做客户端、Web 1.0、Web 2.0、论坛、博客都要考虑架构的问题,架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构,分析一下架构里面哪些共性大家可以参考。
首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户,我们的基层架构也发展了3个大的版本。第一版就LAMP架构,优点是可以非常快的实现我们的系统。我们看一下技术特点,微博这个产品从架构上来分析,它需要解决的是发表和订阅的问题。我们第一版采用的是推消息模式,假如说我们一个明星用户他有10万个粉丝,那就是说用户发表一条微博的时候,我们把这个微博消息存成10万份,这样就是很简单了,第一版的架构实际上就是这两行字。第一版的技术细节,典型的LAMP架构,是使用MyISAM搜索引擎,它的优点就是速度非常快。
另外一个是MPSS,就是多个端口可以布置在同一服务器上。为什么使用MPSS?假如说我们做一个互联网应用,这个应用里面有三个单元,我们可以由2种部署方式。我们可以把三个单元分别部署在三台服务器上,另外一种部署模式就是这三个单元部署在每个服务器上都有。我推荐第2种方法。这个方法解决了两个问题,一个是负载均衡,因为每一个单元都有多个节点处理,另外一个是可以防止单点故障。如果我们按照模式1来做的话,任何一个节点有故障就会影响我们系统服务,如果模式二的话,任何一个结点发生故障我们的整体都不会受到影响的。
我们微博第一版上线之后,用户非常喜欢这个产品,用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象,尤其是明星用户他的粉丝多系统需要处理很长时间。另外系统在处理明星用户发表时系统繁忙可能会影响到其他的用户,因为其他的用户同一时间发表的话,也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式,这肯定是延迟的首要原因,我们要把这个问题解决掉。其次我们的用户越来越多,这个数据库表从一百万到一亿,数据规模不一样处理方式是有差别的。我们第一版单库单表的模式,当用户数量增多的时候,它不能满足就需要进行拆分。第二个是锁表的问题,我们考虑的是更改引擎。另外一个是发表过慢,我们考虑的是异步模式。
第二版我们进行了模块化,我们首先做了一个分层,最底层叫基础层,首先对数据做了拆分,图上最右边是发表做了异步模式。第二个服务层,我们把微博基础的单元设计成服务层一个一个模块,最大改进是对推模式进行了改进。首先看一下投递模式的优化,首先我们要思考推模式,如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝,我发一条微博的时候不需要推给一百个粉丝,因为可能有50个粉丝不会马上来看,这样同步推送给他们,相当于做无用功。我们把用户分成有效和无效之后,我们把他们做一下区分,比如说当天登陆过的人我们分成有效用户的话,只需要发送给当天登陆过的粉丝,这样压力马上就减轻了,另外投递的延迟也减小了。
我们再看数据的拆分,数据拆分有很多方式,很多互联网产品最常用的方法,比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的数据,所以我们考虑微博的数据我们按照时间拆分,比如说一个月放一张表,这样就解决了我们不同时间的维度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的uid,微博id是索引数据,140个字的内容是内容数据。假如我们分开的话,内容就简单的变成了一种key-value的方式,key-value是最容易扩展的一种数据。索引数据的拆分具有挑战,比如说一个用户发表了一千条微博,这一千条微博我们接口前端要分页访问,比如说用户需要访问第五页,那我们需要迅速定位到这个记录。
假如说我们把这个索引拆分成一个月一张表,我们记录上很难判断第五页在哪张表里,我们需要加载所有的索引表。如果这个地方不能拆分,那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法,就是索引上做了一个二次索引,把每个月记录的偏移记下来,就是一个月这个用户发表了多少条,ID是哪里,就是按照这些数据迅速把记录找出来。
异步处理,发表是一个非常繁重的操作,它要入库、统计索引、进入后台,如果我们要把所有的索引都做完用户需要前端等待很长的时间,如果有一个环节失败的话,用户得到的提示是发表失败,但是入库已经成功,这样会带来数据不一致问题。所以我们做了一个异步操作,就是发表成功我们就提示成功,然后在后台慢慢的消息队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ,我们去年做了一个对大规模部署非常有利的指令,就是statsqueue,适合大规模运维。
第二版我们做了这些改进之后,微博的用户和访问量并没有停止,还有很多新的问题出现。比如说系统问题,单点故障导致的雪崩,第二个是访问速度问题因为国内网络环境复杂,会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值,MySql复制延迟、慢查询,另外就是热门事件,比如说世界杯,可能会导致用户每秒发表的内容达到几千条。我们考虑如何改进,首先系统方面允许任意模块失败。另外静态内容,第一步我们用CDN来加速,另外数据的压力以及峰值,我们需要将数据、功能、部署尽可能的拆分,然后提前进行容量规划。
另一方面我们还有平台化的需求,去年11月我们就说要做开放平台,开放平台的需求是有差异的,Web系统它有用户行为才有请求,但是API系统特别是客户端的应用,只要用户一开机就会有请求,直到他关闭电脑这种请求一直会不间断的过来,另外用户行为很难预测。
系统规模在持续的增大,另外也有平台化的需求,我们新架构应该怎么做才能满足这些需要?我们看一下同行,比如说Google怎么样考虑这个问题的?Google首席科学家讲过一句话,就是一个大的复杂的系统,应该要分解成很多小的服务。比如说我们在Google.com执行一个搜索查询的话,实际上这个操作会调动内部一百多个服务。因此,我们第三版的考虑就是先有服务才有接口最后才有应用,我们才能把这个系统做大。
现在我们看一下第三版,首先我们把底层的东西分成基础服务,基础服务里面有分布式的存储,我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务,我们把微博常用的应用做成各种小的服务。然后我们还有应用服务,这个是专门考虑平台各种应用的需求。最上面我们有API,API就是新浪微博各种第三方应用都在上面跑。
平台服务和应用服务是分开的,这样实现了模块隔离,即使应用服务访问量过大的话,平台服务不会首先影响。另外我们把微博的引擎进行了改进,实现了一个分层关系。用户的关注关系,我们改成一个多惟度的索引结构,性能极大的提高。第四个层面就是计数器的改进,新版我们改成了基于偏移的思路,就是一个用户他原来读的一个ID比如说是10000,系统最系的ID是10002的话,我们很清楚他有两条未读。原来的版本是采用绝对计数的,这个用户有几条未读都是用一个存储结构的话,就容易产生一致性的问题,采用这种偏移的技术基本上不会出错。
另外基础服务DB冷热分离多维度拆分,在微博里面我们是按照时间拆分的,但是一个大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分,这个按照UID来拆分可能更简单。然后我们突出存储还做了一个去中心化,就是用户上传图片的速度会极大的提高,另外察看其他用户的图片速度也会极大的提高。另外是动态内容支持多IDC同时更新,这个是在国内比较新颖的。
下面给大家介绍一下新浪微博怎么样打造一个高性能架构。到目前为止有五千万用户使用新浪微博,最高发表3000条以上每秒,然后一个明星用户发表的话,会被几百万用户同时读到。这些问题的本质是我们架构需要考虑高访问量、海量数据的情况下三个问题。易于扩展、低延迟、高可用和异地分布。我们每天有数十亿次外部网页以及API接口的需求,我们知道微博的特点是用户请求是无法cache的。因此面对这个需求我们怎么样扩展?几点思路。第一我们的模块设计上要去状态,我们任意一个单元可以支持任意节点。另外是去中心化,避免单点及瓶颈。另外是可线性扩展。最后一个是减少模块。
我们要做一个高性能的系统,要具备一个低延迟、高实时性,微博要做到高实时性这是核心的价值,实时性的核心就是让数据离CPU最近,避免磁盘的
IO。我们看淘宝核心系统专家余锋说过的一句话“CPU访问L1就像从书桌拿一本书,L2是从书架拿一本书,L3是从客厅桌子上拿一本书,访问主存就像骑车去社区图书馆拿一书”。我们微博如果要做到非常实时的话,我们就需要把数据尽量离CPU节点最近。所以我们看一下cache设计里面怎么达到这个目标。首先INBOX,这个数据我们需要放再一个最快的地方,因为用户随时访问。OutBOX里面的最近发表就是L1cache,还有一个是中期的,这个因为访问少一点,它可以被踢。最后一部分内容体有三部分。L0是本地的,我们需要把一些经常访问的,比如说明星发表微博的内容体本地化,因为它被访问的概率非常大。然后L1里面存放着最近发表的,还有一个是中期的。我们通常用L2就可以了,L1我们可以理解成它就是一个RAM存储。
一个好的架构还需要举行高可用性。我们看一下业界的指标,S3是99.9%,EC2是99.5%,我们另外一个同行Facebook在这方面它是没有承诺的,就是接口可用写。微博平台目前承诺的是99.95%,就是说一天365天故障率应该小于9小时。这个怎么达到?第一我们要做容量规划,要做好监控以及入口的管理,就是说有些服务如果访问量过了的话,我们要有一个开关可以拦住他。我们通过这个图表可以清楚的看到,比如说我们要做L1的cache,我们剩余空间有多少,比如说80%,就说明这个数据有可能会丢失,有可能会对我们的系统造成影响。
另外一个层面就是接口监控,我们目前有Google维度的接口监控,包括访问错误失败率。然后要做架构,给大家一个很重要的经验分享,就是说监控的指标尽量量化。比如说他延迟30秒是小问题,如果是延迟10分钟我们就要立即采取措施了,就是所有可以量化的指标都要量化。
然后我们看监控怎么样更好的做?我们看亚马逊的VP说过的一句话,就是说监控系统确实特别好,可以立即告诉我们哪里有故障,但是有20%的概率我们人是会出错的。所以我们一个大型系统就应该要为自动化设计,就是说尽可能的将一些运作自动化。比如说发布安装、服务、启用、停止。我们再看另外一句,Google的工程师是怎么做的。他是这么做的,比如说第一周是处理线上的业务,这一周他处理了很多事情,处理了很多系统的情况,剩下几周时间没有别的工作,他只要把这一周碰到的情况用程序的方法来解决,下次再碰到这种情况很简单的一个按钮就可以处理了。我们目前也在向自动化这方面努力,就是我们的工具在持续增加。
另外一个异地分布,在国内网络环境下,比如说IDC灾难,机房检修甚至是机房掉电,我们也碰到过中国最好的机房也会掉电,所以要每个服务单元都能支持多机房部署。另外做多机房部署有一个好处,就是用户的访问速度会提高。多IDC分布静态内容就不说了,基本上大的互联网公司都会做,它非常成熟基本上没有什么问题,比如说图片等等的静态内容。动态内容的CDN分布是业内的难点,国内很少有公司能够做到非常成熟的多机房动态内容发布的成熟方案,它的核心就是分布式存储。一款理想的分布式存储产品它有哪些需求呢?首先它要支持海量规模、可扩展、高性能、低延迟、高可用。第二个是需要多机房分布,能够满足国内负责的网络环境,还要具备异地容灾能力。第三个就是要调用简单,具备丰富数据库特性。因此分布式存储需要解决一个多对多的数据复制。
如果要做复制无非是三种策略,第一个是Master/Slave,但是它也两个缺点,第一个是Master是中心化的,如果Master在北京那广州访问就非常慢。第二个缺点是有单点风险的,比如说Master在北京,能立即迁到广州吗?这样有个时间窗口的数据就丢失了,而且需要人工的干预,而且日常广州的用户访问北京的Master是有很大延迟问题的,所以一般来说要做的非常优秀是不会考虑第一种方案的。第二种就是Multi-Master方案,它需要应用避免冲突,就是我们不能多处改变。这个对于微博来说不会特别难,我们的用户通常只会再一个地方发表微博,用户不会同时在广州又在北京发表或者是修改自己的资料,这样的话我们应用上就已经避免了这种情况。第三个就是Paxos就是可以达到强一致写,就是一条数据如果成功肯定是多个机房都成功了,这个也显而易见就是延迟性非常大。因此总结一下Multi-Master是最成熟的策略,但是它现在没有成熟的产品,因为确实没有。
我们再来看微博的方案,所以我们自己实现了一个多机房同步的方案。就是我们前端应用将数据写到数据库,再通过一个消息代理,相当于通过我们自己开发的一个技术,将数据广播到多个机房。这个不但可以做到两个机房,而且可以做到三个、四个。具体的方式就是通过消息广播方式将数据多点分布,就是说我们的数据提交给一个代理,这个代理帮我们把这些数据同步到多个机房,那我们应用不需要关心这个数据是怎么样同步过去的。
用这种消息代理方式有什么好处呢?可以看一下Yahoo是怎么来做的?第一个是数据提供之后没有写到db之后是不会消失的,我只要把数据提交成功就可以了,不需要关心数据怎么到达机房。第二个特点YMB是一款消息代理的产品,但是它唯一神奇的地方是为广域网设计的,它可以把多机房应用归到内部,我们应用不需要关注这个问题。这个原理跟我们目前自己开发的技术相似。
然后我们再看一下目前即将推出的微博平台的新架构。我们知道API大部分的请求都为了获取最新的数据。API请求有一个特点,它大目前调用都是空返回的,比如说一款手机的客户端每隔一分钟它都要调用服务器一下,就是有没有新数据,大目前的调用都是空返回,就是说不管服务器有没有数据都要调用一次。这次询问到下一次询问中间,如果有新的数据来了,你是不会马上知道的。因此我们想API能不能改用推的方式,就是客户端不需要持续的调用,如果有新数据就会推过去。技术特点,显而易见低延迟,就是从发表到接受1秒内完成,实际上可能用不了1秒。然后服务端的连接就是高并发长连接服务,就是多点都连接在我们的服务器上,这个比传统的API要大很多。
我们看一下推送架构怎么从架构底层做到实时性的。从左上角的一条微博在我们系统发布之后,我们把它放在一个消息队列里面,然后会有一个消息队列的处理程序把它拿过来,处理以后放到db里面。假如说我们不做持久化,因为我们推送数据也不能丢失,我们就要写一个很复杂的程序,将数据异步去存,这样就会非常复杂,而且系统也会有不稳定的因素。从另外一个角度来说,我们做持久化也是做过测试的。我们推送整个流程可以做到100毫秒和200毫秒之间,就是说我们在这个时间能把数据推送出去。
我们再看一下内部细节,就是我们收到数据之后首先要经过最上面RECEIVER。然后推到我们的引擎里面,这个引擎会做两个事情,首先会把用户的关系拿过来,然后按照用户关系马上推送给他相应的粉丝。所以我们调用方已经在那儿等待了,我们需要有一个唤醒操作,就是说在接口这儿把它唤醒,然后把它发送过去。最后是一个高并发的长连服务器,就是一台服务器支持10万以上的并发连接。最右边中间有一个圆圈叫做Stream Buffer,我们需要Stream Buffer是要保存用户最近的数据。因为用户可能会有断线的,比如说他发送数据的时候断线半分钟,我们需要把这半分钟补给他。这就是我们的推送架构。
下面介绍一下平台安全部分。由于我们的接口是完全开放的,所以我们要防范很多恶意行为,有很多人担心我们接口是开放的,是不是有人通过这个接口发垃圾广告,或者是刷粉丝,我们技术架构怎么来防范这一点呢?这是我们的安全架构,做了三个层面的事情。最上面是我们有一个实时处理,比如说根据频度、内容的相似性来进行判断,判断发的是不是广告或者是垃圾内容。中间这个是一个日志处理器,我们会根据一些行为进行判断,比如说如果我们只是实时拦截的话,有些行为很难防止,我们做了个离线纠正的模块,比如说他潜伏的几个月开始发广告了,我们可以事后把这些人清除掉,以保证我们平台的健康。最后是通过监控的维度来保证内容的安全。目前内容安全的架构大概是541的体系,就是说我们的实时拦截可以做到50%的防止,离线分析大概可以做到40%的防止。
微博平台需要为用户提供安全及良好的体验应用,以及为开发者营造一个公平的环境,所以我们的接口需要清晰安全的规则。从一个APP调用我们的接口,需要几个阶层,需要划分不同的业务模块。第二个是安全层。第三个是权限层。这是我们平台安全的两个维度,一个接口安全,一个是内容安全。
我今天讲的是架构方面的问题,在座大部分是开发者,可能大家都在处理不同的架构问题,架构很多地方是相通的。我们需要做一个软件系统需要解决的本质问题是什么?微博第一版解决发布规模问题,第二版是解决数据规模的问题,第三版是解决服务化的问题。将复杂的问题简单化之后,我们才可以设计出一个容易扩展的大规模架构。我今天介绍就这么多,我们微博实际上是很需要各方面的技术人员,大家对我们的架构如果感兴趣的话、对我们的系统感兴趣的话,也希望各方面的技术人员参与我们微博的团队,随时可以给我微博上发私信。
发表评论
-
Windows Mobile与Android应用开发对比
2011-09-06 11:44 1330Windows Mobile在经历过最初的Wince系列,po ... -
android 调用C++的so
2011-07-08 18:36 4423第一步:开发环境的安 ... -
CentOS环境下opensuse虚拟机的创建
2011-02-24 09:41 1413CentOS环境下opensuse虚拟机的创建 1. ... -
unix下C编程
2011-02-21 16:44 1066http://www.chinaunix.net/jh/23/ ... -
linux操作系统下c语言编程入门<unix操作系统下同样适用>——Linux程序设计入门--消息管理
2011-02-21 16:40 1077[color=blue]6)Linux程序设计入门--消息管理 ... -
linux操作系统下c语言编程入门<unix操作系统下同样适用>——Linux程序设计入门--信号处理
2011-02-21 16:39 1282[color=blue]5)Linux程序设计入门--信号处理 ... -
linux操作系统下c语言编程入门<unix操作系统下同样适用>——Linux程序设计入门--时间概念
2011-02-21 16:38 1136[color=blue]4)程序设计入 ... -
linux操作系统下c语言编程入门<unix操作系统下同样适用>——Linux程序设计入门--文件操作
2011-02-21 14:48 992[color=blue]3)Linux程序设计入门--文件操作 ... -
linux操作系统下c语言编程入门<unix操作系统下同样适用>——Linux程序设计入门--进程介绍
2011-02-21 14:43 1268[color=blue]2)Linux程序设计 ... -
linux操作系统下c语言编程入门<unix操作系统下同样适用>——Linux程序设计入门--基础知识
2011-02-21 14:17 1473<! ... -
为什么在操作系统中引入虚拟技术呢
2010-12-21 23:17 1440通过虚拟技术将一台独占设备虚拟成多台逻辑设备,供多个用户进程同 ... -
虚拟设备和 Open Virtualization Format
2010-12-21 23:15 1300虚拟设备和 Open Virtualization Forma ... -
如何用puttygen由pem生成ppk
2010-11-09 13:48 210491. 概述 因为内存3GB的限制在自己的笔记本电脑上通常不能 ... -
linux开机启动服务进程
2010-11-04 21:30 16801)redhat的启动方式和执 ... -
linux开机启动过程
2010-11-04 21:28 1344一.BIOS 加电自检 当你按电源开关开机时,电脑会首先 ... -
(原创)自动扫描局域网并且发现指定端口开放的主机ip的shell脚本
2010-11-04 21:10 6614经过2天研究,学习shell和awk脚本,得到如下功能: 1 ... -
AWK命令详解(大全)
2010-11-03 21:25 1924什么是awk? 你可能对UNIX比较熟悉,但你可能对aw ... -
使用 awk 处理 nmap 扫描结果,求出存活主机IP
2010-11-03 21:22 3736在使用 nmap 扫描时,得到如下结果: ... -
awk基础
2010-11-03 21:21 1303awk语言 最基本功能是在文件或字符串中基于指定规则浏览和抽 ... -
awk教程
2010-11-03 21:19 1319文章分类:操作 ...
相关推荐
- **大会背景**:2010年11月16日,新浪微博举办了首届开发者大会,标志着新浪微博正式迈向开放平台的新阶段。此次大会旨在分享新浪微博的开发情况和发展规划,探讨微博产业的未来方向,并为开发者提供一个交流合作的...
内容概要:本文详细探讨了利用NSGA2算法进行电力系统中储能系统的选址和定容优化,并结合熵权TOPSIS方法选择最优解。首先介绍了使用Matpower工具包进行潮流计算的基础步骤,随后深入讨论了储能系统引入后的复杂性和优化目标设定。文中展示了如何构建目标函数,包括储能的投资成本和系统电压偏差,并详细解释了NSGA2算法的具体实现,如种群初始化、交叉变异操作以及约束条件处理。最后,通过熵权法确定权重并应用TOPSIS方法对多个优化结果进行评估,选出综合性能最佳的储能配置方案。 适合人群:从事电力系统规划、优化算法研究的专业人士,尤其是对储能系统优化感兴趣的科研人员和技术开发者。 使用场景及目标:适用于需要解决电力系统中储能系统选址和定容问题的实际工程项目。主要目标是在满足系统稳定性要求的前提下,最小化储能系统的投资成本,提高系统的经济性和可靠性。 其他说明:文章提供了详细的代码片段和理论推导,帮助读者更好地理解和实施所提出的优化方法。此外,还提到了一些实际应用中的注意事项,如SOC约束处理、参数选择等,为后续的研究和应用提供了宝贵的实践经验。
基于python+pyqt5实现视频自动化下载、剪辑和上传系统源码+项目说明.zip 该项目是用脚本实现部分视频网站视频内容的自动化下载、剪辑以及上传,其中界面是用PyQT做的。 使用的浏览器驱动是undetected_chromedriver,可以跳过tiktok的机器人检查 使用的浏览器是91,版本:Google_Chrome_(64bit)_v91.0.4472.77 【功能】 自动从各种视频网站下载视频 支持视频剪辑和合集制作 支持自动上传视频到视频网站 技术栈 Python PyQT undetected_chromedriver
内容概要:本文详细介绍了西门子S7-1200双套三坐标6轴联动控制系统的开发与调试经验。主要内容涵盖双PLC通信机制、轴控制逻辑、安全联锁设计以及触摸屏程序绑定等方面。文中通过具体代码示例展示了如何利用SCL语言实现高效稳定的多轴联动控制,并分享了实际项目中的最佳实践和技术难点解决方案。此外,还讨论了程序结构优化、报警代码设计、数据块管理等关键环节,强调了模块化设计思想的应用及其带来的效率提升。 适合人群:从事工业自动化领域的工程师,尤其是熟悉西门子PLC编程的专业人士。 使用场景及目标:适用于需要进行复杂运动控制的自动化生产线,如汽车制造、电子装配等行业。主要目标是提高生产效率,确保设备运行的安全性和稳定性。 其他说明:文中提到的许多技术和方法不仅限于特定型号的PLC,对于其他品牌的控制器也有一定的借鉴意义。同时,提供的代码片段可以直接应用于类似项目中,帮助开发者快速搭建可靠的控制系统。
NFC Tools是一个应用程序,允许你在你的 NFC 标签和其他 RFID 兼容芯片上读取或写入或编程代码任务。NFC Tools PRO版本包括很多其他的附加功能,比如配置文件管理等。保存你的NFC标签或任务的配置文件,以便你以后重新使用它们。导出和导入很容易。NFC Tools PRO官方版允许你直接从现有的 NFC 标签导入你的记录或任务。 你可以很快编辑你的标签。此外还可以直接运行你的任务配置文件,不需要NFC 标签。
该资源为protobuf-6.30.1-py3-none-any.whl,欢迎下载使用哦!
内容概要:本文详细介绍了如何在FLAC3D中提取壳单元和衬砌单元的关键内力数据,如弯矩、轴力和剪力。针对壳单元,文中提供了具体的FISH命令和函数,展示了如何利用gp.extra属性提取弯矩,并强调了局部坐标系方向的重要性。对于衬砌单元,则介绍了专门的命令和注意事项,如使用liner组件提取轴力和剪力,以及如何处理弯矩数据。此外,还分享了一些实用的经验和技巧,如批量数据处理、单位换算、内力符号规则等。最后,提到了使用Python进行后处理的方法,将提取的数据转化为更直观的形式,便于进一步分析。 适合人群:从事岩土工程、隧道工程及相关领域的工程师和技术人员,尤其是对FLAC3D有一定基础的用户。 使用场景及目标:帮助用户掌握FLAC3D中壳单元和衬砌单元内力提取的具体方法,提高工作效率,确保数据分析的准确性。适用于需要进行结构内力分析、支护设计优化等项目的工程师。 其他说明:文章不仅提供了详细的命令和函数示例,还分享了许多实战经验和常见错误的规避方法,有助于初学者少走弯路。同时,强调了内力符号规则和单位换算的重要性,避免因疏忽导致的重大失误。
内容概要:本文详细介绍了ST公司发布的HL07:ST PMSM FOC电机控制资料包2.0的内容及其应用。资料包涵盖了ST芯片电机控制的全源代码、详细文档、多个工程源码、stm32库培训资料及例程源码。文中通过具体的代码示例,如GPIO初始化、PWM配置、ADC采样、Clarke变换、PID调节器、SVPWM生成等,深入剖析了电机控制的关键技术和优化技巧。此外,还揭示了一些隐藏的技术细节和调试技巧,如硬件同步、动态调整PID参数、电机参数自识别等。 适合人群:电机控制工程师、嵌入式开发人员、尤其是对STM32和FOC算法感兴趣的开发者。 使用场景及目标:帮助读者深入了解ST芯片电机控制的具体实现,掌握从硬件配置到算法优化的全过程,提高实际项目的开发效率和质量。适用于需要进行电机控制系统设计、调试和优化的工程项目。 其他说明:资料包中的代码和文档非常实用,提供了丰富的实战经验和优化建议,尤其适合初学者和有一定基础的研发人员。同时,文中提到的一些特殊技巧和注意事项有助于避免常见的开发陷阱,提升系统的稳定性和性能。
内容概要:文章探讨了2025年AI技术发展趋势及潜在的GPT级技术突破。首先回顾了GPT系列模型的发展历程及其对自然语言处理领域的深远影响。接着,通过介绍Geoffrey Hinton、李飞飞和张晨等AI领袖的观点,阐述了AI技术在实际应用场景中的挑战与机遇。文中详细描述了AI大模型的演进,包括多模态技术的发展、轻量化趋势以及可控性和可解释性的提升。此外,还介绍了AI计算力的革命性升级,如量子计算、云计算+AI和边缘AI的发展。最后,文章分析了AI在医疗、金融、教育、自动驾驶等行业的落地应用,并指出了面临的挑战与机遇,展望了未来的技术和社会影响。 适合人群:对AI技术感兴趣的从业者、研究人员、企业家及政策制定者。 使用场景及目标:①了解AI技术的最新进展和未来趋势;②探索AI技术在各行业的应用前景;③评估AI技术带来的挑战与机遇,为相关决策提供参考。 阅读建议:本文内容涵盖广泛,既有技术细节又有宏观展望,建议读者结合自身背景选择感兴趣的部分深入阅读,重点关注与自身行业或研究方向相关的章节。
内容概要:本文详细探讨了基于樽海鞘算法(SSA)优化的极限学习机(ELM)在回归预测任务中的应用,并与传统的BP神经网络、广义回归神经网络(GRNN)以及未优化的ELM进行了性能对比。首先介绍了ELM的基本原理,即通过随机生成输入层与隐藏层之间的连接权重及阈值,仅需计算输出权重即可快速完成训练。接着阐述了SSA的工作机制,利用樽海鞘群体觅食行为优化ELM的输入权重和隐藏层阈值,从而提高模型性能。随后分别给出了BP、GRNN、ELM和SSA-ELM的具体实现代码,并通过波士顿房价数据集和其他工业数据集验证了各模型的表现。结果显示,SSA-ELM在预测精度方面显著优于其他三种方法,尽管其训练时间较长,但在实际应用中仍具有明显优势。 适合人群:对机器学习尤其是回归预测感兴趣的科研人员和技术开发者,特别是那些希望深入了解ELM及其优化方法的人。 使用场景及目标:适用于需要高效、高精度回归预测的应用场景,如金融建模、工业数据分析等。主要目标是提供一种更为有效的回归预测解决方案,尤其是在处理大规模数据集时能够保持较高的预测精度。 其他说明:文中提供了详细的代码示例和性能对比图表,帮助读者更好地理解和复现实验结果。同时提醒使用者注意SSA参数的选择对模型性能的影响,建议进行参数敏感性分析以获得最佳效果。
内容概要:本文详细介绍了汇川PLC与基恩士PLC通过Ethernet/IP (EIP) 协议实现联机的方法及其应用场景。首先,文章解释了硬件配置,包括基恩士KV-7300 CPU搭配KV-EP21v以太网通信模块以及汇川AM-400系列PLC的网口连接。接下来,分别阐述了基恩士和汇川PLC的程序框架,涵盖初始化EIP通讯模块、设置IP地址、建立连接、数据映射及心跳检测机制等关键技术点。此外,文中提供了具体的代码示例和调试建议,如使用Wireshark抓包工具排查问题,并强调了数据同步、字节序转换、超时处理等方面需要注意的地方。最后,分享了一些实践经验,例如确保正确的IP地址分配、合理的缓冲区大小规划、良好的接地措施等。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是对PLC编程有一定基础并希望深入了解不同品牌PLC间通讯机制的专业人士。 使用场景及目标:适用于需要将不同品牌PLC集成到同一个控制系统中的工业项目,旨在提高系统的灵活性和互操作性。通过掌握本文介绍的技术要点,可以有效减少因PLC品牌差异带来的兼容性和稳定性问题。 其他说明:文中不仅提供了理论指导,还结合实际案例进行了深入浅出的讲解,帮助读者更好地理解和应用相关技术。同时,针对可能出现的问题给出了预防和解决方案,使读者能够在实践中少走弯路。
内容概要:本文详细记录了作者将VESC项目的非线性磁链观测器移植到STM32F4开发板的过程。首先介绍了FOC技术和VESC源码的重要性和特点,然后重点阐述了非线性磁链观测器的实现方法及其核心代码。接着讨论了移植过程中遇到的技术难题,如实时性、稳定性、中断处理、电流采样等问题,并分享了解决这些问题的具体措施。最后展示了测试结果,证明了移植的成功以及观测器的良好性能。 适合人群:具有一定嵌入式开发经验的研发人员,特别是从事电机控制领域的工程师和技术爱好者。 使用场景及目标:适用于希望深入理解VESC源码和非线性磁链观测器的工作机制,掌握STM32F4平台上FOC算法实现的人群。目标是在实际项目中应用这些技术,提高电机控制系统的性能。 其他说明:文中提供了大量实用的代码片段和调试技巧,帮助读者更好地理解和解决问题。此外,作者还分享了一些个人经验和心得,增加了文章的趣味性和实用性。
移远EC20 Windows驱动 操作系统 - 桌面系统 - 移远EC20 Windows驱动
检证资料jianzhen.ppt
内容概要:本文档《ATK-DLRK3568嵌入式Qt开发实战V1.2》是正点原子出品的一份面向初学者的嵌入式Qt开发指南,主要内容涵盖嵌入式Linux环境下Qt的安装配置、C++基础、Qt基础、多线程编程、网络编程、多媒体开发、数据库操作以及项目实战案例。文档从最简单的“Hello World”程序开始,逐步引导读者熟悉Qt开发环境的搭建、常用控件的使用、信号与槽机制、UI设计、数据处理等关键技术点。此外,文档还提供了详细的项目实战案例,如车牌识别系统的开发,帮助读者将理论知识应用于实际项目中。 适合人群:具备一定Linux和C++基础,希望快速入门嵌入式Qt开发的初学者或有一定开发经验的研发人员。 使用场景及目标: 1. **环境搭建**:学习如何在Ubuntu环境下搭建Qt开发环境,包括安装必要的工具和库。 2. **基础知识**:掌握C++面向对象编程、Qt基础控件的使用、信号与槽机制等核心概念。 3. **高级功能**:理解多线程编程、网络通信、多媒体处理、数据库操作等高级功能的实现方法。 4. **项目实战**:通过具体的项目案例(如车牌识别系统),巩固
1、文件说明: Centos8操作系统tcl-tclxml-devel-3.2-26.el8.rpm以及相关依赖,全打包为一个tar.gz压缩包 2、安装指令: #Step1、解压 tar -zxvf tcl-tclxml-devel-3.2-26.el8.tar.gz #Step2、进入解压后的目录,执行安装 sudo rpm -ivh *.rpm
C盘清理bat脚本自动清理C盘垃圾文件
桶排
内容概要:本文详细介绍了利用混沌系统进行图像加密的方法,重点探讨了Logistic映射生成混沌序列用于图像加密的具体实现。首先,通过生成混沌序列并对其进行预热处理,确保序列的随机性和稳定性。然后,采用循环移位扰乱方法对图像像素进行重新排列,使图像像素位置发生改变。接着,通过水平和垂直扩散步骤进一步打乱像素之间的关联性,增强了加密效果。文中还展示了如何通过直方图、信息熵和相关系数等指标评估加密效果,验证了该方法的有效性。 适合人群:对图像加密技术和混沌系统感兴趣的科研人员、信息安全领域的开发者和技术爱好者。 使用场景及目标:适用于研究和开发高效的图像加密算法,特别是在需要高安全性的应用场景中,如军事通信、隐私保护等领域。目标是提供一种基于混沌系统的高效、安全的图像加密解决方案。 其他说明:文中提供了详细的Python代码实现,帮助读者更好地理解和实践该加密方法。同时,强调了在实际应用中需要注意的一些关键点,如参数选择和优化,以确保最佳的加密效果。
基于EEMD奇异值熵的滚动轴承故障诊断方法研究