rails3品种解析之1——系统架构

  • 运作单线程(多核CPU无法丰裕利用)处理多客户端并发连接请求,接纳了异步非阻塞
    IO
    模型(epoll)。四线程自然是能够比单线程有更高的习性上限,但在后天的持筹握算环境中,即便是单机二十四线程的上限也不可能满足实际须求了,因此单机单线程集群化安顿是实用消除方案;
  • 不予赖libevent这么些追求通用而导致代码庞大的库,用libevent中的八个文本修改完成了温馨的epoll
    event loop,小巧并去保护,编译Redis之前并不须要执行./configure;
  • Redis 2.0充实了虚拟内存(Virtual Memory,Redis本身完成的比OS
    Page更细的换入出粒度)天性,完成了冷热数据分离,让数据体积突破了物理内存的限制;
  •  协助多样类型的数据结构,如strings, hashes, lists, sets, sorted sets
    with range queries, bitmaps, hyperloglogs and geospatial indexes
    with radius queries;
  • 支撑Cache-Only、Persistence三种存储方式,Persistence可分AOF(Append-Only
    File)、汉兰达DB(Redis
    Database)二种机制(但法定提议二种格局还要开启,参考Redis
    Persistence
    ),可用来crash后从磁盘恢复生机,不过都设有或许有失数据(数据可信性)难点。从读缓存这些角度讲,平时我们的应用可以承受那种多少丢失带来的震慑,倘诺利用需求更高的多少可靠性,那就不应当对该类数据应用缓存服务;

    RDB:在save、shutdown、slave时触发写二进制文件,粒度大,如果这些操作未完成之前crash可能导致丢失一部分数据。
         通过fork一个进程,copy-on-write把整个db保存下来,而主进程不会进行任何IO操作,保证了redis的高性能。
    
    AOF:持续把写操作命令格式化后追加到日志文件的尾部,粒度较小,crash之后数据丢失小。AOF支持不同的fsync策略,
         包括无fsync、每秒fsync、请求时fsync,默认为每秒fsync策略。fsync是由后台线程完成的,主线程继续努
         力地执行写请求。AOF是文本文件,通常也比RDB文件大,恢复速度慢。
    
  • Redis襄助Cluster、Master-Slave
    replication,由于Redis的高质量,replication基本没有延迟,那样达到了防护单点故障及完毕了高可用;

  • Redis援救工作:watch/multi/exec(discard、unwatch);
  • list可用来落实队列;
  • Redis
    pipeline技术能够在服务端未响应时,客户端可以一连向服务端发送请求,并最终三次性读取所有服务端的响应。

在可预料的前途,即2到3年内,推测流量将达到10-100万PV/天。因而在拓展统筹时,以该流量作为本架构可以承接的上限。借使网站确实有幸活到了几百万PV以上的流量,那自然就不缺钱了,凡是钱能消除的标题,都不是什么大难题。 

  1. 安装PhpRedis:那是其官方参考文档 https://github.com/phpredis/phpredis#usage,某些用法只怕与Illuminate\Redis不同

    pecl install redis (有可能需要手动安装 autoconf,phpize依赖该工具)
    composer require illuminate/redis
    

    注意事项:该C增添安装完后急需修改php.ini添加行extension=redis.so。若是php在cli方式下运维未察觉Redis,可能是因为你的php.ini文件并未找到,该公文为设置配备项–with-config-file-path所指定,暗中认同位于PREFIX/lib目录下,所以应在开行php时添加-c选项指定安插文件或php.ini所在目录。

  2. redis客户端配置:中央同于Predis,唯一不一样之处在于lumen/vendor/laravel/lumen-framework/config/database.php中redis的client,’client’
    => ‘phpredis’

  3. 注册Illuminate\Redis\RedisServiceProvider:同于Predis
  4. 测试PhpRedis是还是不是中标启用:同于Predis
  5. 除此以外一种无需安装illuminate/redis包就能启用PhpRedis的交替用艺术:

    1)修改lumen/bootstrap/app.php,添加如下代码:

    $app->singleton('redis', function(){
        $redis = new Redis;
        $redis->pconnect('172.17.0.3');
        return $redis;
    });
    unset($app->availableBindings['redis']);
    

    2)测试PhpRedis是或不是中标启用,修改lumen/routes/web.php:

    $app->get('/', function () use ($app) {
        //return $app->version();
        app('redis')->set('lumen', 'Hello, Lumen.');
        return app('redis')->get("key");
    });
    

     

2、关于业务方式和流量的推论,看得出来你很有经历,只是微微抬举大家了。我们是个小网站,刚上线没多久,还并未伊始大范围放大,流量很小。不过固然流量大了,大家也不太想选用静态页面那种方法。因为终归网站工作还没成型,须要转变很快。网络业务的风味就是形成,有或许今日的静态页面,明日就要大范围变更和调整,可能突然须求加上很多动态的情节。而且象金融情报那种比较正式的网站,一般也到持续网易那种有要求运用静态页面的程度。由此在一定长的一段时日内,大家还没有设想静态页面。单纯的资讯页面,加上缓存,几台服务器支撑一下大概难点不大的。 

  1. 创建Dockerfile-Redis(参考https://github.com/dockerfile/redis/blob/master/Dockerfile ):

    FROM ubuntu
    MAINTAINER cenze <272666745@qq.com>
    
    RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
    ADD conf/sources.list /etc/apt/
    RUN apt-get update \
    && apt-get install -y gcc make vim
    
    ENV PKGS="/usr/local/pkgs"
    ADD packages/redis-3.2.8.tar.gz $PKGS/
    
    # install redis
    ENV PREFIX_REDIS="/usr/local/redis"
    WORKDIR $PKGS/redis-3.2.8
    RUN make \
    && make PREFIX=$PREFIX_REDIS install \
    && cp redis.conf $PREFIX_REDIS/ \
    && cp src/redis-trib.rb $PREFIX_REDIS/bin/ 
    
    VOLUME ["/data"]
    ENV PATH $PREFIX_REDIS/bin:$PATH
    
    EXPOSE 6379
    
    CMD ["redis-server","/usr/local/redis/redis.conf"]
    

    注意事项:

    • Redis命令参考:https://redis.io/commands
    • 作者已事先下载了PhpRedis的源码安装包redis-3.2.8.tar.gz位于宿主机
      ./packages目录下
    • redis.conf中撤销行 bind 127.0.0.1
      或鲜明绑定 IP地址集,其余容器才可访问 
    • redis.conf中若未安装密码,只怕需安装
      protected-mode 为 no以关闭怜惜情势,protected-mode 暗中认同值为
      yes
    • 设置目录的bin下有个redis-cli可拷到其余容器中作为命令行接口来三番五次管理redis服务端
    • 卷/data用于缓存数据对象的持久化存储目录
  2. 构建镜像:

    sudo docker build -t cenze/redis -f Dockerfile-Redis .
    
  3. 运营容器:

    sudo docker run -d --name redis cenze/redis
    

    redis-cli或netcat(nc)或telnet测试布署:

    root@60c9de8c01a0:/usr/local/pkgs/redis-3.2.8# redis-cli
    127.0.0.1:6379> set cache redis
    OK
    127.0.0.1:6379> get cache
    "redis"
    127.0.0.1:6379>  
    

     

瞩望能收看楼主越来越多的经验,小编也愿意在ror使用中享受部分东西,希望对境内ror会有所推进。大家早已在跑的一台ror服务器是apache2.0.x+passenger,不是最优的选配,以往会再调动,数据库是MySQL,前端就加了个memcached,因为不是做WEB,是做的API用的,每一天接口调用在240万次左右,等负荷高了自然还得优化系统、加服务器呀。数据库方面读取都cache在memcached里面了,写操作是通过文件缓存来做的,比较简单:每一种数据insert或然update等请求写一个文件文件,不用加锁,其它有进度定时扫描这个文件,入库后删之,所以MySQL负载很轻。

 

5.5
glusterfs也持有水平增添能力,再与nginx结合直接出口文件,可承接较大流量。 

四.Lumen中启用PhpRedis扩展

2、架构设计 

  • memcached采取Slab
    Allocation机制基于hashmap来完成对内存对象的开创与治本,容量(哈希表中桶的多少)和加载因子(容积自动增加此前可以高达多满的一种规格)影响其脾性。当哈希表中的条目数超越了加载因子与当前容积的乘积时,则要对该哈希表进行rehash
    (重建内部数据结构),从而哈希表将有着大体两倍的桶数。在Java编程语言中,加载因子私自认同值为0.75,暗中认可哈希表元为101。
    图片 1
  • memcached若是运营在暗许状态下,应放置在防火墙后端;
  • 在停放空间被占满之后,memcached接纳惰性失效(Lazy
    Expiration)机制和Least Recently Used(LRU)机制来做淘汰管理;
  • 基于libevent的事件处理,运营多线程处理多客户端并发连接请求,虽说也支撑分布式,但服务端并从未分布式作用,互相无法相互通讯,完全器重于客户端完毕,故障转移也不提供冗余节点,一旦某节点发生故障将造成相应的数量不可用;
  • 客户端libmemcached可使用各样哈希算法(MD5、CLX570C等)总括key,对非标量类型数据如数组、对象(非能源类型才能被种类化)等将先举行种类化然后再发送给服务端,匡助Multi操作;
  • CAS(Check And Set)是Memcached中相比方便的一种预防竞争修改财富的章程

    A 64bit "CAS" value, which is kept unique.
    
  • 支撑文件协议和二进制协议三种紧要的协议。别的,还支持子协议SASL
    Authentication、Range
    operations。相关音信参考 https://github.com/memcached/memcached/wiki

    上面那段是关于文本协议“noreply”的讲述,同时指出选用二进制协议:

    Most ASCII commands allow a "noreply" version. One should not normally use this with the ASCII protocol, as it is impossible to align errors with requests. The intent is to avoid having to wait for a return packet after executing a mutation command (such as a set or add).
    
    The binary protocol properly implements noreply (quiet) statements. If you have a client which supports or uses the binary protocol, odds are good you may take advantage of this.
    

    上面那段是有关“A Well Designed Binary Protocol Client”的讲述:

    With the binary protocol, it(A Well Designed Binary Protocol Client may take many application threads and use a single TCP connection back to memcached) is possible to pack requests from different client instances into the same TCP socket, then dole back results to the right owners.
    
  1. ree 1.8.7 rails 3.0.8    # 基础平台  

  2. rake 0.9.2  gem 1.8.5  bundler 1.0.14    # 基础工具  

  3. mysql2 0.2.7  ruby-oci8  activerecord-oracle_enhanced-adapter    #
    数据库驱动  

  4. nokigiri  yajl-ruby    # 解析器  

  5. authlogic  cancan    # 权限和讲明  

  6. ckeditor  paperclip  rmagick    # 编辑器和图表  

  7. redis-store 1.0.0.rc1  mongoid 2.0.2    # nosql  

  8. resque  resque-scheduler  eventmachine    # 异步和定时职分  

  9. capistrano  capistrano-ext    # 代码发表  

  10. open-flash-chart  formtastic  rspec  spork    # 杂项  

  Redis 与
Memcached 均为常用的 key-value
分布式内存对象缓存系统,可提供数据缓存和多少共享能力,Redis
帮衬持久化,而 memcached
不扶助持久化,爆发重启后数据不会自行回复。

服务器发行版采取ubuntu
server,也毕竟一种个人爱好吧。作为rails的运转平台,无论是种种零部件的安装仍然难点的消除,相对都相比较顺遂。至少就作者个人感觉,ubuntu就像是早就改为rails平台的标配,网上的学科和示范大部分都以以ubuntu为根基的。我们也曾经在铺子遗留的centos上设置过rails,有一部分难点要么很麻烦的。 

三.Lumen中启用Predis**

本人不领悟页面渲染的标题是rails3本人的难题,照旧我们在何方没有设置好,一向没有很好地消除。近期用了ree官方推荐的GC优化参数,此外再对首页划分partial,做一些缓存,以后渲染时间在200ms左右。当然,我们还留了一部分从没做一些缓存的,是为着等着哪一天老板问大家首页能无法再快一点,我们再把剩余的丰盛缓存,那样每趟工作义务都会有显着的业绩。。。。。。 

 二.创建Lumen项目

3.5 glusterfs 3.2.0。使用原生的双机互备方案。 

  1. composer创建Lumen:composer``无法以 root/super 用户来运行,所以需要切换到其他用户环境,比如本人会运行如下命令

    su - www-data 
    export PATH=/usr/local/php/bin:$PATH (这一条最好写进Home下的.profile, composer依赖PHP来运行) 
    composer create-project --prefer-dist laravel/lumen lumen
    
  2. .env参数配置:

    APP_ENV=local
    APP_DEBUG=true
    APP_KEY=bcee22b233721b47c6043e6bf35ac4ee
    APP_TIMEZONE=Asia/Shanghai
    
    DB_CONNECTION=mysql
    DB_HOST=[myDbHost]
    DB_PORT=3306
    DB_DATABASE=[myDataBase]
    DB_USERNAME=[myUser]
    DB_PASSWORD=[myPassword]
    
    CACHE_DRIVER=redis
    QUEUE_DRIVER=sync 
    
    REDIS_HOST= 172.17.0.3
    REDIS_PORT= 6379
    

     

5.2
应用层的恢弘比较简单,只需追加应用服务器节点即可。负载均衡的nginx可以设置权重以抵消负载。 

  1. 安装Predis:Lumen中动用Predis须求引入
    predis/predis 和 illuminate/redis三个包

    cd /path/to/lumen
    composer require illuminate/redis (predis/predis为illuminate/redis所依赖,故将被自动安装上)
    
  2. **redis客户端**配置****修改lumen/vendor/laravel/lumen-framework/config/database.php

    'redis' => [
    
            'client' => 'predis',
            //'client' => 'phpredis',
    
            'cluster' => env('REDIS_CLUSTER', false),
    
            'default' => [
                'host'     => env('REDIS_HOST', 'localhost'),
                'port'     => env('REDIS_PORT', 6379),
                'database' => env('REDIS_DATABASE', 0),
                'password' => env('REDIS_PASSWORD', null),
            ],
    
        ],
    
  3. 注册Illuminate\Redis\RedisServiceProvider:修改lumen/bootstrap/app.php

    $app->register(Illuminate\Redis\RedisServiceProvider::class);
    
    $app->withFacades();//同时启用Facades
    
    $app->withEloquent();//同时启用Eloquent
    
  4. 测试Predis是不是中标启用:修改lumen/routes/web.php

    $app->get('/', function () use ($app) {
        //return $app->version();
        Cache::put('lumen', 'Hello, Lumen.', 5);
        return Cache::get('lumen');
    });
    

    页面输出:Hello, Lumen.

2.2
高可用方案。
主干组件采取keepalived,使用master-backup机制来实施主备服务器的实时切换。 

  关于Memcached:

自然我是想通过修改activerecord来兑现mysql
master-master的全自动服务转移,后来觉得比较费心,所以就没做,省了个事用keepalvied来落到实处。借使真要做保证的mysql高可用,如故提出在rails端化解,可能是用更好的法门解决两台mysql数据同步的绝密争论,比较好一些。其实最好的如故原生方案,象mongodb那样的,在数据库的局面就防止那些难题,那是最优的缓解方案。 

  Lumen
基于 Laravel 创设,专为营造微服务和 APIs
而生。Lumen与Redis服务端通讯可经过Predis(PHP库)恐怕PhpRedis(PHP的C伸张)来贯彻,指出采用PhpRedis,其属性更高。Lumen下拔取Predis和PhpRedis都需引入illuminate/redis(PHP库),illuminate/redis(PHP库)都对Predis和PhpRedis(Laravel
5.3之上)举办了很好的卷入,但illuminate/redis(PHP库)又凭借predis/predis(PHP库),故安装 illuminate/redis时会自动引入predis/predis(PHP库)。

用rails3做目前的这一个网站项目,已经有3个月多了。大家以此团队应该算是比较早选取rails3做项目标,3.0业内版刚发布就从头尝试了,在项目支出时期针对广大题材也做了一部分探索。谈不上经历,更称不上最佳实践,只是分享出来,经学见易,法家见淫,有亟待的情侣各取所需。小商店小品种,适用于初中级用户,大牛们可一笑而过。 

一. Redis的Docker部署

本子更新上,ubuntu已经不输于centos,能够说有过之而无不及。从效率安全上,少安装点不要求的包,iptable规则严峻一点,时常自动更新内核,也就几乎了。至于使用习惯,大家社团依然都更习惯ubuntu的,终究开发桌面以ubuntu居多,都以如出一辙家的男女,desktop和server是世代相承的。多机负载均衡小编倍感centos和ubuntu没怎么实质上的分歧,不知底您所指是哪方面。 

  至于Redis(REmote
DIctionary Server,
远程字典服务器)
SSDB支撑LevelDB,是Redis的替代品,且与其相当。

多年来正值为定时任务而头痛。cron +
rake的CPU占用率实在是个难点。看了LZ的小说决定尝试resque去。 
BTW,eventmachine还足以做定时任务吗? 

2.8
异步和定时执行。
使用resque用作基础架构执行异步任务,以resque-scheduler举办定时任务。同样,也以双机互备来担保无遗失地爆发和推行职责队列。经过那几个月的应用,除了化解了有的与其他系统互相时不期而然的连串堵塞难题,近日看来resque照旧值得信任的。 

3、技术选型 

根据预测流量,在可预料的年月阶段,结合该品种的运转需求和预算财力,网站显要以高可用(HA)和有限的档次增加性(scale
out)为中央架构理念,选用分布式无共享架构(distributed share nothing
architecture),使用rails暗中认可的cookie_store机制来所有和拍卖session,化解了有只怕变成品质瓶颈的集中式session的老毛病。而且在架构设计时,使得系统负荷尽量平均分配到每台服务器上。 

5.4
redis和mongodb都相比较便于水平扩充,多加服务器,做集群配置,即可分散流量拉长负载。 

4.2
公布管理。
 使用 capistrano 作为宣布工具,结合capistrano-ext的multistage功效对多少个例外的公告环境展开管理。并且结合了bundler的capistrano模块对bundle
gems进行发表时的电动安装管理,做到了测试版本和业内版本的一键化发表。在99%的情况下不需求报到服务器其余做布置或改动。 

服务器操作系统使用ubuntu server 10.04.2
x64,正在测试11.04,如可用并有利于,则有恐怕在新硬件上设置使用。11.04法定协理到二零一二年10月份,对人类来说已经足足。2012事后,所有服务器已荡然无存。 

只是,依然不可以否认mongodb确实很精粹,尤其是和mongoid合作起来,用得很顺手。 

体系基本架构就是如此,限于篇幅,很多地点都以一带而过。下一步我准备写如下内容,留作个人积累和合作社文档,包罗但不幸免: 

您说的mysql的负载均衡,是指mysql ndb
cluster吗。大家也评估过它,一是觉得太复杂,对我们的种类有些有志无时,二是大家看过一些网上的评价,很多用过的人大概持保留态度的。就到底mysql
proxy之类的读写分离方案,如故觉得有些复杂。就像mysql原生的扩张方案都令人不是很爽快,所以索性就只用replication做高可用了,实质上依然单机。后边小编也说过,对大家的档次来说,结合nosql,单机也够用了。若是实际要扩张mysql,倒不如直接用handler_socket来得彻底。 

2.5
数据库。
应用2台mysql,做master-master复制,合作keepalived完成高可用。 

2.4
应用层。
使用ree+passenger+nginx作为rails
web服务器,passenger易于管理维护,而且和ree协作较好。所有应用服务器地位均等,每台服务器均发表总体的门类代码,不在功效上做分布式,以利于维护。 

经济音信网站,向用户提供经济金融情报,公布和宣扬集团研发的种种金融产品,指导用户注册和买卖产品。当前网站的情节出自是商店的情报平台和物价指数数据库,通过http接口和oracle
sql获取数据并展现,恐怕在中短时间会有用户互动和用户原创内容(UGC)的须求。 

在技巧路线上,团队有着最大的自由度,由此大家可以依照自个儿的意见举行技能布局,而且可以大胆地运用新型的技术架构和平消除决方案,在做到公司支出职务的还要提升社团技术水平,紧跟业界技术风尚。 

图片 2

4.4
测试。
 由于多数职能都以调用此外平台或访问走势数据库,逻辑相比简单,由此 rspec 用得不太多,仅在开发接口等一些商业逻辑上应用。这是体系近来的一个缺点,今后会刻意加强测试方面的代码量。 

因此大家未来的支付理念是把数量存储于mysql,mongodb里的数码只是mysql数据的复制和冗余,用那份冗余来以空间换时间。万一出现数量不雷同,就以mysql为准向mongodb同步数据。那只是大家团队近来所利用的艺术而已。

5.3
mysql不太好伸张,但如前方所言,把负载尽量分散到nosql上,在百万PV级别,mysql也就无需增加了。实在要增添,能够尝尝做读写分离等方案,或等候几年后mysql解决更美观的水平增添方案。 

keepalived本人是比较成熟的,在front-end用keepalived来做高可用,也好不简单比较早熟。但是个人感觉keepalived自己有部分局限性,比如服务器完全挂掉的时候keepalived很管用,但借使服务器常规,但地面的nginx服务无响应,就相比较费心了。keepalived尽管也有检测本地服务的模块,但并不是一检测到地头服务失效就随即切换来另一台,不是自个儿想要的成效。作者商讨了一段时间也没找到消除方案,不明了是自小编没找到,照旧自然就这么。 

Ruby代码图片 3

一流缓存使用内存数据库redis,优点是速度快,并发高。用于存储首页缓存数据,保存股票市价数据,以及同盟redis-store作为rails暗许页面缓存,等等。目前储存数据约2800条,使用内存100M。 

5.1
负载均衡的习性取决于接受请求的那台服务器的个性,nginx的面世依旧让人放心的。固然日后品质成为瓶颈了,可以用更好的服务器,大概换硬件沟通机,直至F5。 

在数据库的选择上,考虑到观念的关系型数据库已不太适应当下网络接纳的雅量数据和高负荷特点,由此mysql只起到第一数据存储功效,利用事务性和成熟性,保险网站数据的一体化和兴安盟。然后加入非关系型数据库redis和mongodb,作为数据冗余存储和计算大旨,承载绝一大半的高负载数据请求,可实用减小mysql的下压力。那样就不必费心配置复杂难用的可增加mysql集群,使用单台mysql服务器即可承载较高的网站流量。而redis和mongodb天生就是为互连网应用设计的,它们的集群配置和品位增加相对尤其简易方便。听他们讲未来已经有团体只利用mongodb来作为网站数据库,向他们的时尚和大无畏,致以我们公司深刻的珍贵。 

3、gluster确实目的相比较远大。而且当初大家采用它,也是因为它不改变操作系统内核,所以再怎么折腾也不会对系统造成沉重的震慑。大家脚下用的最紧要照旧gluster的replication高可用的这部分意义,有局部小意思(比如没有文档中所说的活动同步),但近年来总的来说依然可用的。至于将来会不会用到distributed和striped等横向扩展,到时再说。说不定到时有钱了就上硬件了。走一步看一步吧。 

对技术人士没什么太高要求,keepalived相比简单,文档也算充实,一般的技术人士都能看了然并且安插成功。

3.4 mongodb
1.8.1。mongodb自己有原生的replset方案来兑现多少同步和容错转移,由此在mongodb的层面一贯动用该方案,配置2台服务器即可达成高可用。 

1、要说到“独立”安装这么一套系统,确实是有点复杂,但也不是专门困难。只要把安装文档写详细了,根据步骤来设置服务器,应该难点不大,无非就是部分apt-get之类的,再加上些配置。把布置文件备份好了第一手回复就很快了。代码安插是用capistrano写的,多少个指令就化解,也不设有困难。相比辛勤的是真正清楚这套系统,而且出了难题能领略在何处,那就看个人的福分了。大牛私奔总是相比较胸闷的事,所以大家团队的目的是把逐个人都构建成大牛,私奔多少个都不怕。 

2.6 缓存系统 
缓存系统分为顶尖缓存和二级缓存。拔尖缓存用于存储数据量不大,但对进程须要高的缓存数据。二级缓存用于存储对速度须求相对较低,但存储量巨大的数目。 

6、请问一下您的mysql
5.5主备,是如何是好的。5.5不恐怕在布署文件里写主备复制的参数了,你是用脚本做的,依然起步起来然后再登录mysql敲命令?

keepalvied协作mysql的master-master复制来做高可用,是自己要好雕刻的。做完了未来在网上一搜,才意识早已有人如此做了。但这么些方案并不是很干练,主倘使因为mysql的复制是有一段极小的时间距离的,假如在mysql尚未同步完结时,keepalived就切换了骨干,不难造成mysql的id重复。当然那也得以解决,比如设置自增id的宽窄即可,然而小编不爱好那样。但总的说来,keepalived合作mysql,不是很干练。 

1、keepalived的配备和采用,优缺点。 
2、rails 3的助益,特性化设置,存在的后天不足和临时化解方案。 
3、redis和mongodb的主从复制架构,相关难点的消除方案,各自的特点和基本功运用。 
4、glusterfs的配置和应用。 
5、resque种类组件的采用,异步和定时任务履行。 

因为rails3的架构更复杂,所以个人感觉要比rails2运行速度慢。从服务器的起步到页面的渲染,实测的流年都要更长。尤其是rails3的页面渲染,网站首页内容一经相比多以来,渲染速度大约不可接受。 

不错呀,看了收益很多,公司内部就大家team在做ruby on
rails尝试,都要起来积累呀,尽管相比累,不过很有意思,危害上很小,都以针对性卖家里面的田间管理种类上做尝试,允许出错。此外,集团评论已经上mongodb了,15台服务器的规模,貌似在境内是最大的了呢?不过我们ror组还没用mongodb,语言换新的就很累了,数据库再换了就会疯掉的。 

2.3 负载均衡 
按照网站流量和实在须要,使用nginx用作七层互换,把前端进来的用户请求round-robin到后端的应用服务器。nginx辅助容错转移,假使后端的某台应用服务器失效,nginx可把该台服务器暂时移出可用列表。 

4.1
源码管理。
 使用 git ,拔取所谓的“稳定分支形式”。有3个第一的支行:master、alpha、production。源码合并的逐条一般情况下是master
-> alpha ->
production。master用于日常支出,alpha用于揭橥测试版本,production用于公布生产环境的正统版本。即使有hotfix或许feature的急需,再另开任何临时分段。各种开发人员对持有支行都富有一切读写权限,使用公钥认证的ssh访问源码库。 

不是用eventmachine做定时职责,它是底层组件。resque-scheduler要利用rufus-scheduler,rufus的定时有三种达成方式,一是plain格局,就是用sleep来做loop,二就是em方式,假使系统中装置了eventmachine,rufus会自动使用em情势。

4.3
项目管理。
 使用 redmine 作为项目管理平台,能够和git库有机地整合起来。 

有道是也是为着谋求尽量贴合项目其实的方案吗,假设集团报告大家做个一千万PV的,大家也就不用未来那套方案了。

再者,由于负载均衡服务器位于整个网站种类的最前端,一旦失效则全部网站随即瘫痪,所以其重点无与伦比。为保障高可用,使用keepalived达成双服务器的故障实时切换。 

2.1 软硬件平台 
目前正在运行的硬件是6台dell
2U二手服务器,总价大概在1.6万,物美价廉,居家必备。如今应用可以。别的借公司发展南风,已有8台全新dell刀片进入机房,正准备把方方面面系统迁移至新服务器上。 

单台服务器如同XX的应允,永远都以靠不住的。单台服务器会死机、掉电、停转、拔线,所以在架设中尽最大或者幸免各个作用组的单点故障,做到在服务器集群中,任意一台服务器失效,或几台不相干服务器同时失效,网站仍可不奇怪运转。而且无单点故障的架构,服务器可每日重启,也有益操作系统的基础升级和安全补丁等平常维护工作。经过这多少个月的连年使用,各类原因的两次单点故障均没有影响到网站日常服务。 

你们在front-end server和db-server那里都用keepalived来确保高可用性.
那么些方案成熟么? 对技术人员的渴求怎么着? 

能不大概给个网站两次三番,大概几乎讲哈
投入运行后越到的难题。以后,很多少人对Ruby 的运维效果有很大的疑点。 

6、测试和产品多环境下的capistrano一键发表连串。 

4、项目管理 

1、网站须求 

实质上无论作为ruby,照旧rails,当前的运作效果已经够用。在网站选拔的层面,尽管出现一些效能难点也可以从软件和硬件等次第层面解决。与rails开发和掩护所节省的日子人力等首要花费相比,消除那些题材都以值得的。当然了,不引进用rails做凝聚、实时或并行运算。用最合适的言语,做最契合的事情。

3.3 redis
2.2.8。因为官网说redis原生的cluster方案,有恐怕将在二零一一年5月才出CRUISERC版,所以近来大家使用redis的master-slave机制,自个儿写了一个监控脚本,同盟keepalived,已毕两台redis服务器之间的数据同步(replication)和容错转移(failover),以此来完毕高可用。 

率先期的开支从2010.11开头,到二〇一一年元辰上线,大概为2个月的时日。上线后又经历了大体上1个月,基本稳定达标近期的情况。纯代码约1万行。开发人士4名。开发平台有ubuntu
desktop和windows
7,开发工具有aptana、netbeans、emacs等。对平台和工具不做须要,在dos下能把活干好,也行。 

干什么对全Mongo后台有顾虑? 
nosql的观点和mongodb数据库终归是新东西,诞生时间还相当长,不象sql理论和mysql经过了好久的狠毒考验。而且mongodb以后未曾太多的极品实践,担心出了难点无法便捷化解。所以就是小编精晓mongodb确实很平稳很不错,但如故不太敢于把订单和用户等首要数据存放于此。此外今后mongodb还从未实际的管理工具标准,使用上稍有困难。 

二级缓存使用文档型数据库mongodb,优点是查询效率强大,帮助海量存储。用于存储部分谍报内容,升高页面响应速度。近年来储存数据约10万条,数据文件大小为4G。 

5、以后扩展 

2.7
文件系统。
使用glusterfs,以其自己的编制可达成双机热备和单台服务器失效重临后文件的自动同步。用户上传的文件会自行地同时保留于2台glusterfs服务器上。对应用程序来说,它们只是将文件保留于地面某个指定目录,glusterfs对使用是晶莹剔透的。而且其他一台服务器单独失效都不会对用户暴发可察觉的熏陶,失效的服务器再次来到后,glusterfs会统计2台服务器所保存文件的歧异,对转移过的文件举办共同。 

5、nfs当然很可靠,只是作者没找到怎么用nfs做高可用,一台服务器自己又不放心,所以就找到了gluster来做这么些,而且在gluster上也是用的nfs协议,包容性不错。至于说访问文件的快慢,那一个大家从不通过gluster的read接口来做,我们只是用gluster来写文件,下载的时候绕过gluster直接用nginx读取本地文件,速度上临时并未难题。 

3.1 网站选择rails
3开发,用到的机要组件和版本如下。未注脚版本号的,为流行版本。 

转自: http://www.iteye.com/topic/1058510 
这厮相对大牛了。。

大家及时选型的时候也设想过cron形式,但运用cron来跑定时,与操作系统绑定太紧,不便于公布和护卫。用resque-scheduler,所有定时职责都写在一个配置文件里,清晰易懂便于维护,而且发布后只须求kill掉rescue-scheduler的常驻rake再重启,即可刷新定时职责规则,方便快速。 

3.2 数据库。使用mysql
5.1。因为5.5打消了在文书中配置replication,只可以手动命令执行,个人感觉相比费心,无法形成服务器的无人值守。若是有同学找到了5.5机关配置的方案,还望赐教。谢谢。 

4、你的架构不或者说简陋,其实最简易的才是最可行的。小编于是做的如此复杂,也是因为自身那人爱折腾,平日悠闲就升级个服务爱抚启下怎么样的,所以才做个尚未单点的架构。个人爱好而已。呵呵。 

在服务器版本的抉择上比较奇怪,为何选拔采用Ubuntu这一个称霸个人桌面的服务器版? 
自个儿对Ubuntu的纪念还只逗留在个人版(从7.1到8.04)。 
何以不考虑拔取Centos?个人感觉无论从版本更新,功效安全,照旧采取习惯上都要更好些。而且多机负载均衡也好处理些。 
其余,Mysql自个儿的负荷均衡也很圆满,不过从您文中好像没看出来有很好的行使? 

发表评论

电子邮件地址不会被公开。 必填项已用*标注