首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    针对nginx、haproxy、lvs 的优缺点分析

    Nginx的优点:          1.性能好,可以负载超过1万的并发。          2.功能多,除了负载均衡,还能作Web服务器,而且可以通过Geo模块来实现流量分配。          3.社区活跃,第三方补丁和模块很多          4.支持gzip proxy   缺点:           1.不支持session保持。意思是:用户找Nginx请求一个PHP的页面,输入了用户名,密码。接着用户可能又开了一个新窗口,新窗口开了后,还是访问之前个的服务器,此时,Nginx会当成一个新的请求来处理,这样可能会导致请求被分发给其它的后端服务器。因为其不支持session保持           2.对后端realserver的健康检查功能效果不好。而且只支持通过端口来检测,不支持通过url来检测。           3.nginx对big request header的支持不是很好,如果client_header_buffer_size设置的比较小,就会返回400 bad request页面。 Haproxy的优点:          1.它的优点正好可以补充nginx的缺点。支持session保持,同时支持通过获取指定的url来检测后端服务器的状态。          2.支持tcp模式的负载均衡。比如可以给mysql的从服务器集群和邮件服务器做负载均衡。此点相比LVS讲,差一些! 缺点:          1.不支持虚拟主机(这个很傻啊)          2.目前没有nagios和cacti的性能监控模板 LVS的优点:           1.性能好,接近硬件设备的网络吞吐和连接负载能力。           2.LVS的DR模式,支持通过广域网进行负载均衡。这个其他任何负载均衡软件目前都不具备。    缺点:           比较重型。另外社区不如nginx活跃。 -------------------------------------------------------------------------------------------------------- nginx lvs 负载均衡 lvs和nginx都可以用作多机负载的方案,它们各有优缺,在生产环境中需要好好分析实际情况并加以利用。 首先提醒,做技术切不可人云亦云,我云即你云;同时也不可太趋向保守,过于相信旧有方式而等别人来帮你做垫被测试。把所有即时听说到的好东西加以钻研,从而提高自己对技术的认知和水平,乃是一个好习惯。 下面来分析一下两者: 一、lvs的优势:    * 1、抗负载能力强,因为lvs工作方式的逻辑是非常之简单,而且工作在网络4层仅做请求分发之用,没有流量,所以在效率上基本不需要太过考虑。在我手里的 lvs,仅仅出过一次问题:在并发最高的一小段时间内均衡器出现丢包现象,据分析为网络问题,即网卡或linux2.4内核的承载能力已到上限,内存和 cpu方面基本无消耗。    * 2、配置性低,这通常是一大劣势,但同时也是一大优势,因为没有太多可配置的选项,所以除了增减服务器,并不需要经常去触碰它,大大减少了人为出错的几率。    * 3、工作稳定,因为其本身抗负载能力很强,所以稳定性高也是顺理成章,另外各种lvs都有完整的双机热备方案,所以一点不用担心均衡器本身会出什么问题,节点出现故障的话,lvs会自动判别,所以系统整体是非常稳定的。    * 4、无流量,上面已经有所提及了。lvs仅仅分发请求,而流量并不从它本身出去,所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。    * 5、基本上能支持所有应用,因为lvs工作在4层,所以它可以对几乎所有应用做负载均衡,包括http、数据库、聊天室等等。 另:lvs也不是完全能判别节点故障的,譬如在wlc分配方式下,集群里有一个节点没有配置VIP,会使整个集群不能使用,这时使用wrr分配方式则会丢掉一台机。目前这个问题还在进一步测试中。所以,用lvs也得多多当心为妙。 二、nginx和lvs作对比的结果    * 1、nginx工作在网络的7层,所以它可以针对http应用本身来做分流策略,比如针对域名、目录结构等,相比之下lvs并不具备这样的功能,所以 nginx单凭这点可利用的场合就远多于lvs了;但nginx有用的这些功能使其可调整度要高于lvs,所以经常要去触碰触碰,由lvs的第2条优点看,触碰多了,人为出问题的几率也就会大。    * 2、nginx对网络的依赖较小,理论上只要ping得通,网页访问正常,nginx就能连得通,nginx同时还能区分内外网,如果是同时拥有内外网的节点,就相当于单机拥有了备份线路;lvs就比较依赖于网络环境

    03

    完整的一套直播系统平台开发需要哪些技术支持?

    如今,直播已经成为了人们生活中必不可少的产品了,不仅仅通过实时直播带来的娱乐和欢乐,还有更重要的是它带来的实时信息分享,由此直播也带来了非常大的商业价值和潜力。不仅是现在的秀场直播,现在慢慢兴起的教育、电商等,都在一步步的跨入直播领域,可见直播的领域应该还存在更大的潜力等待我们去挖掘。 那么,直播系统平台开发到底需要哪些技术呢?需要了解哪些方面的知识呢? 首先开发实时直播时需要了解哪些知识: 摄像头采集; 1、音视频编解码; 2、流媒体协议; 3、音视频流推送到流媒体服务器; 4、流媒体网络分发; 5、用户播放器; 6、音视频同步; 7、网络延迟自适应; 8、需要录制,多种视频文件的格式和封装; 9、语言:C、C++、html、php、mysql...... 10、开发环境:嵌入式,Linux,Windows,Web...... 还有就是视频播放解决方案(卡顿、延迟): 1、CDN 加速; 2、自己架服务器; 3、用别人的云服务。 用 CDN 加速,可以尽量减少延迟。目前业内水准来看,视频延迟都在 3-6 秒之间。也就是在视频直播时,你看到的是几秒以前的画面。 自己架服务器,如果部署的数据中心不够多,那么遇上跨网、跨省的传输,还是得用 CDN 加速。那么为了尽可能降低延迟,你就需要在全国各省市都部署数据中心,来解决跨网、跨省的传输。用云服务的话,就是别人把服务器给你架好了,你只要傻瓜式的用就行了。当然,不管用哪种方式,综合权衡利弊,找到适合的方案就是最好的方案。 开发视频直播的流程有哪些: 1、采集; 2、前期处理; 3、编码; 4、传输; 5、解码; 6、渲染。 采集:iOS 是比较简单的,Android 则要做些机型适配工作。PC 最麻烦各种奇葩摄像头驱动,出了问题特别不好处理,建议放弃 PC 只支持手机主播,目前几个新进的直播平台都是这样的。 前期处理:现在直播美颜已经是标配了,80%的主播没有美颜根本没法看。美颜算法需要懂图像处理算法的人,没有好的开源实现,要自己参考论文去研究。算法设计好了还要优化,无论你打算用 CPU 还是 GPU 优化,算法优化本身也需要专业知识支持。GPU 虽然性能好,但是也是有功耗的。GPU 占用太高会导致手机发烫,而手机发烫会导致摄像头采集掉帧。而这一切都是需要经验支撑。 编码:如果你要上 720p,肯定要采用硬编码。软编码 720p 完全没希望,硬件编码不灵活。兼容性也有问题。如何适应纷繁复杂的网络和纷繁复杂的上下行设备?安卓和芯片的坑,开发过的人都知道。那有人问,要求不高,上软编码低分辨率 360p 行不行?就算上低分辨率,软编码还是会让 CPU 发烫,CPU 过热烫到摄像头,长期发烫不仅直接反应是费电。既然是手机直播,插着电源和充电器实在说不过去吧。还有,CPU 发烫会降频,怎么办?这还是只说性能方面。和前处理只影响图像质量和功耗不同,视频编解码技术还关联成本计算和网络对抗。考虑性能、功耗、成本、网络这四个之后你编码的码率、帧率、分辨率。软硬件开发该如何选择? 传输:自己做不现实,交给第三方服务商吧。 解码:如果你用硬解码,一定要做容错处理,一定要做适配。突然一个crash导致手机重启不好吧。安卓的硬解码,不说了。如果你加了网络目前手机的硬解码还不一定支撑用软解码,功耗发热的问题又来了。 渲染:为什么手机明明解码出好多帧数据。就是渲染不出来。为什么画面就是不同步。 以上是媒体模块,还有信令控制,登录、鉴权、权限管理、状态管理等等,各种应用服务,消息推送,聊天,礼物系统,支付系统,运营支持系统,统计系统等。后台还有数据库,缓存,分布式文件存储,消息队列,运维系统等。 以上技术要点的小结,确实能说明开发一个能用于生产环境的实时视频直播平台确非易事,跟IM里传统的实时音视频一样,这样的技术都是音视频编解码+网络传输技术的综合应用体。

    03

    SQL Server的六种数据移动方法

    1.通过工具DTS的设计器进行导入或导出       DTS的设计器功能强大,支持多任务,也是可视化界面,容易操作,但知道的人一般不多,如果只是进行SQL   Server数据库中部分表的移动,用这种方法最好,当然,也可以进行全部表的移动。在SQL   Server   Enterprise   Manager中,展开服务器左边的+,选择数据库,右击,选择All   tasks/Import   Data...(或All   tasks/Export   Data...),进入向导模式,按提示一步一步走就行了,里面分得很细,可以灵活的在不同数据源之间复制数据,很方便的。而且可以另存成DTS包,如果以后还有相同的复制任务,直接运行DTS包就行,省时省力。也可以直接打开DTS设计器,方法是展开服务器名称下面的Data   Transformation   Services,选Local   Packages,在右边的窗口中右击,选New   Package,就打开了DTS设计器。值得注意的是:如果源数据库要拷贝的表有外键,注意移动的顺序,有时要分批移动,否则外键主键,索引可能丢失,移动的时候选项旁边的提示说的很明白,或者一次性的复制到目标数据库中,再重新建立外键,主键,索引。         其实建立数据库时,建立外键,主键,索引的文件应该和建表文件分开,而且用的数据文件也分开,并分别放在不同的驱动器上,有利于数据库的优化。         2.   利用Bcp工具         这种工具虽然在SQL   Server7的版本中不推荐使用,但许多数据库管理员仍很喜欢用它,尤其是用过SQL   Server早期版本的人。Bcp有局限性,首先它的界面不是图形化的,其次它只是在SQL   Server的表(视图)与文本文件之间进行复制,但它的优点是性能好,开销小,占用内存少,速度快。有兴趣的朋友可以查参考手册。         3.   利用备份和恢复         先对源数据库进行完全备份,备份到一个设备(device)上,然后把备份文件复制到目的服务器上(恢复的速度快),进行数据库的恢复操作,在恢复的数据库名中填上源数据库的名字(名字必须相同),选择强制型恢复(可以覆盖以前数据库的选项),在选择从设备中进行恢复,浏览时选中备份的文件就行了。这种方法可以完全恢复数据库,包括外键,主键,索引。       4.   直接拷贝数据文件         把数据库的数据文件(*.mdf)和日志文件(*.ldf)都拷贝到目的服务器,在SQL   Server   Query   Analyzer中用语句进行恢复:     EXEC   sp_attach_db   @dbname   =   ’test’,     @filename1   =   ’d:mssql7data   est_data.mdf’,     @filename2   =   ’d:mssql7data   est_log.ldf’         这样就把test数据库附加到SQL   Server中,可以照常使用。如果不想用原来的日志文件,可以用如下的命令:       EXEC   sp_detach_db   @dbname   =   ’test’     EXEC   sp_attach_single_file_db   @dbname   =   ’test’,     @physname   =   ’d:mssql7data   est_data.mdf’         这个语句的作用是仅仅加载数据文件,日志文件可以由SQL   Server数据库自动添加,但是原来的日志文件中记录的数据就丢失了。         5.   在应用程序中定制         可以在应用程序(PB、VB)中执行自己编写的程序,也可以在Query   Analyzer中执行,这种方法比较灵活,其实是利用一个平台连接到数据库,在平台中用的主要时SQL语句,这种方法对数据库的影响小,但是如果用到远程链接服务器,要求网络之间的传输性能好,一般有两种语句:     1>select   ...   into   new_tablename   where   ...     2>insert   (into)   old_tablename   select   ...   from   ...   where   ...       区别是前者把数据插入一个新表(先建立表,再插入数据),后者是把数据插入已经存在的一个表中,我个人喜欢后者,因为在编程的结构上,应用的范围上,第二条语句强于前者。         6.

    03
    领券