首页
关于
标签合集
友情链接
Search
1
一些简单方面的Linux生产随机密码shell
270 阅读
2
美超微主板IPMI使用教程
139 阅读
3
Ubuntu系统开启root登陆权限
134 阅读
4
Centos6升级e2fsprogs
99 阅读
5
利用廉价VPS做反代,保护你的真实服务器
76 阅读
OS
促销资讯
管理系统
网站运维
网文资讯
登录
Search
标签搜索
网站架构
linux
网站运营
centos
mysql
google
nginx
ssh
apache
服务器
kloxo
vps
架构分析
PHP
特价VPS
xen
shell
数据库
lamp
vpn
装逼爱好者
累计撰写
163
篇文章
累计收到
20
条评论
首页
栏目
OS
促销资讯
管理系统
网站运维
网文资讯
页面
关于
标签合集
友情链接
搜索到
52
篇与
的结果
2011-07-07
Facebook图片管理架构
Facebook 的照片分享很受欢迎,迄今,Facebook 用户已经上传了150亿张照片,加上缩略图,总容量超过1.5PB,而每周新增的照片为2亿2000万张,约25TB,高峰期,Facebook 每秒处理55万张照片,这些数字让如何管理这些数据成为一个巨大的挑战。本文由 Facebook 工程师撰写,讲述了他们是如何管理这些照片的。旧的 NFS 照片架构老的照片系统架构分以下几个层:# 上传层接收用户上传的照片并保存在 NFS 存储层。# 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。# NFS存储层建立在商业存储系统之上。因为每张照片都以文件形式单独存储,这样庞大的照片量导致非常庞大的元数据规模,超过了 NFS 存储层的缓存上限,导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题,他们做了两项优化:# Cachr: 一个缓存服务器,缓存 Facebook 的小尺寸用户资料照片。# NFS文件句柄缓存:部署在照片输出层,以降低 NFS 存储层的元数据开销。新的 Haystack 照片架构新的照片架构将输出层和存储层合并为一个物理层,建立在一个基于 HTTP 的照片服务器上,照片存储在一个叫做 haystack 的对象库,以消除照片读取操作中不必要的元数据开销。新架构中,I/O 操作只针对真正的照片数据(而不是文件系统元数据)。haystack 可以细分为以下几个功能层:# HTTP 服务器# 照片存储# Haystack 对象存储# 文件系统# 存储空间存储Haystack 部署在商业存储刀片服务器上,典型配置为一个2U的服务器,包含:# 两个4核CPU# 16GB – 32GB 内存# 硬件 RAID,含256-512M NVRAM 高速缓存# 超过12个1TB SATA 硬盘每个刀片服务器提供大约10TB的存储能力,使用了硬件 RAID-6, RAID 6在保持低成本的基础上实现了很好的性能和冗余。不佳的写性能可以通过高速缓存解决,硬盘缓存被禁用以防止断电损失。文件系统Haystack 对象库是建立在10TB容量的单一文件系统之上。文件系统中的每个文件都在一张区块表中对应具体的物理位置,目前使用的文件系统为 XFS。Haystack 对象库Haystack 是一个简单的日志结构,存储着其内部数据对象的指针。一个 Haystack 包括两个文件,包括指针和索引文件:Haystack 对象存储结构指针和索引文件结构Haystack 写操作Haystack 写操作同步将指针追加到 haystack 存储文件,当指针积累到一定程度,就会生成索引写到索引文件。为了降低硬件故障带来的损失,索引文件还会定期写道存储空间中。Haystack 读操作传到 haystack 读操作的参数包括指针的偏移量,key,代用Key,Cookie 以及数据尺寸。Haystack 于是根据数据尺寸从文件中读取整个指针。Haystack 删除操作删除比较简单,只是在 Haystack 存储的指针上设置一个已删除标志。已经删除的指针和索引的空间并不回收。照片存储服务器照片存储服务器负责接受 HTTP 请求,并转换成相应的 Haystack 操作。为了降低I/O操作,该服务器维护着全部 Haystack 中文件索引的缓存。服务器启动时,系统就会将这些索引读到缓存中。由于每个节点都有数百万张照片,必须保证索引的容量不会超过服务器的物理内存。对于用户上传的图片,系统分配一个64位的独立ID,照片接着被缩放成4种不同尺寸,每种尺寸的图拥有相同的随机 Cookie 和 ID,图片尺寸描述(大,中,小,缩略图)被存在代用key 中。接着上传服务器通知照片存储服务器将这些资料联通图片存储到 haystack 中。每张图片的索引缓存包含以下数据Haystack 使用 Google 的开源 sparse hash data 结构以保证内存中的索引缓存尽可能小。照片存储的写/修改操作写操作将照片数据写到 Haystack 存储并更新内存中的索引。如果索引中已经包含相同的 Key,说明是修改操作。照片存储的读操作传递到 Haystack 的参数包括 Haystack ID,照片的 Key, 尺寸以及 Cookie,服务器从缓存中查找并到 Haystack 中读取真正的数据。照片存储的删除操作通知 Haystack 执行删除操作之后,内存中的索引缓存会被更新,将便宜量设置为0,表示照片已被删除。重新捆扎重新捆扎会复制并建立新的 Haystack,期间,略过那些已经删除的照片的数据,并重新建立内存中的索引缓存。HTTP 服务器Http 框架使用的是简单的 evhttp 服务器。使用多线程,每个线程都可以单独处理一个 HTTP 请求。结束语Haystack 是一个基于 HTTP 的对象存储,包含指向实体数据的指针,该架构消除了文件系统元数据的开销,并实现将全部索引直接存储到缓存,以最小的 I/O 操作实现对照片的存储和读取。本文国际来源:http://www.facebook.com/FacebookEngineering#/note.php?note_id=76191543919&ref=mf中文翻译来源:COMSHARP CMS 官方网站
2011年07月07日
12 阅读
2 评论
0 点赞
2011-07-06
关于大型网站构架的简要分析
一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录下,这样的网站对系统架构、性能的要求都很简单,随着互联网业务的不断丰富,网站相关的技术经过这些年的发展,已经细分到很细的方方面面,尤其对于大型网站来说,所采用的技术更是涉及面非常广,从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网站所能比拟的。 大型网站,比如门户网站。在面对大量用户访问、高并发请求方面,基本的解决方案集中在这样几个环节:使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面,还没法根本解决大型网站面临的高负载和高并发问题。 上面提供的几个解决思路在一定程度上也意味着更大的投入,并且这样的解决思路具备瓶颈,没有很好的扩展性,下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。 1、HTML静态化 其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。 除了门户和信息发布类型的网站,对于交互性要求很高的社区类型网站来说,尽可能的静态化也是提高性能的必要手段,将社区内的帖子、文章进行实时的静态化,有更新的时候再重新静态化也是大量使用的策略,像Mop的大杂烩就是使用了这样的策略,网易社区等也是如此。 同时,html静态化也是某些缓存策略使用的手段,对于系统中频繁使用数据库查询但是内容更新很小的应用,可以考虑使用html静态化来实现,比如论坛中论坛的公用设置信息,这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中,这些信息其实大量被前台程序调用,但是更新频率很小,可以考虑将这部分内容进行后台更新的时候进行静态化,这样避免了大量的数据库访问请求。 2、图片服务器分离 大家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持,尽可能少的 LoadModule,保证更高的系统消耗和执行效率。 3、数据库集群和库表散列 大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。 在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。 上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。 4、缓存 缓存一词搞技术的都接触过,很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。 架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力。 网站程序开发方面的缓存,Linux上提供的Memory Cache是常用的缓存接口,可以在web开发中使用,比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大型社区使用了这样的架构。另外,在使用web语言开发的时候,各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多了,.net不是很熟悉,相信也肯定有。 5、镜像 镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异,比如ChinaNet和 EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点,数据进行定时更新或者实时更新。在镜像的细节技术方面,这里不阐述太深,有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路,比如Linux上的rsync等工具。 6、负载均衡 负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。 负载均衡技术发展了多年,有很多专业的服务提供商和产品可以选择,我个人接触过一些解决方法,其中有两个架构可以给大家做参考。 硬件四层交换 第四层交换使用第三层和第四层信息包的报头信息,根据应用区间识别业务流,将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就象是虚 IP,指向物理服务器。它传输的业务服从的协议多种多样,有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上,需要复杂的载量平衡算法。在IP世界,业务类型由终端TCP或UDP端口地址来决定,在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。 在硬件四层交换产品领域,有一些知名的产品可以选择,比如Alteon、F5等,这些产品很昂贵,但是物有所值,能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。 7、软件四层交换 大家知道了硬件四层交换机的原理后,基于OSI模型来实现的软件四层交换也就应运而生,这样的解决方案实现的原理一致,不过性能稍差。但是满足一定量的压力还是游刃有余的,有人说软件实现方式其实更灵活,处理能力完全看你配置的熟悉能力。 软件四层交换我们可以使用Linux上常用的LVS来解决,LVS就是Linux Virtual Server,他提供了基于心跳线heartbeat的实时灾难应对解决方案,提高系统的鲁棒性,同时可供了灵活的虚拟VIP配置和管理功能,可以同时满足多种应用需求,这对于分布式的系统来说必不可少。 一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性,随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。 对于大型网站来说,前面提到的每个方法可能都会被同时使用到,我这里介绍得比较浅显,具体实现过程中很多细节还需要大家慢慢熟悉和体会,有时一个很小的 squid参数或者apache参数设置,对于系统性能的影响就会很大,希望大家一起讨论,达到抛砖引玉之效。FROM:51CTO
2011年07月06日
4 阅读
0 评论
0 点赞
2011-07-06
Facebook 的 PHP 性能与扩展性
炙手可热的 Facebook 是用 PHP 开发的。随着一些技术交流,逐渐能看到 Facebook 技术人员分享的经验。近期这个 geekSessions 站点上看到 Facebook 的 Lucas Nealan 分享的文档比较有参考价值。Cache 为 王任何一个成功的站点都有一套最合适自己的 Cache 策略。Note:这个层次图画的稍微有点问题,不是严格从上到下的。The Alternative PHP Cache , APCFacebook 平均每个用户每天要访问超过 50 个页面,PHP的页面载入时间的优化就比较重要了。在 PHP Cache 层,Facebook 采用了 APC。关于facebook APC 介绍的PDF.Lucas Nealan 的 PPT 举了一个例子,一个页面显示的时间从 4000 多毫秒降到了 100 多 毫秒。在 apc.stat 关闭的模式下,性能还要更好一些。不过需要重启动或用apc_cache_clear() 来通知更新。Memcached 层APC Cache 的是非用户相关的信息,而用户相关的数据 Cache 当然是在 Memcached 中。Facebook 部署了超过 400 台 Memcached 服务器,超过 5TB 的数据在 Memcached 中。这是当前世界上最大的 Memcached 集群了。也给 Memcached 贡献了不少代码,包括 UDP 的支持和性能上的提升(性能提升超过 20%)。程序 ProfilingFacebook 开发人员大量采用 Callgrind 、APD、 xdebug 、KCachegrind 等工具进行基准性能测试。任何一个 Web 项目,这也是不可或缺,也是比较容易忽略的一环。所有开发人员都应该具备熟练使用这些工具的能力才好。补充一下:语言的选择为什么 Facebook 选择 PHP 而不是其他语言? 用Flickr 的 Cal Henderson 这句话就能说明了: “Languages’s don’t Scale, Architecture Scale”。从 80-20 的原则看,APC 和 Memcached 是最主要的。在这两个环节上下功夫,受益/开销比要大于另外几个环节。(上面的图是从 Lucas Nealan 的文档截的,版权所有是他的)作者: Fenng网址: http://www.dbanotes.net/arch/facebook_php.html
2011年07月06日
7 阅读
0 评论
0 点赞
2011-07-05
MySQL 5.4发布beta版
Sun在第七届MySQL展会上发布了其最新版开源数据库MySQL 5.4的技术预览版本,MySQL 5.4在性能和可伸缩性上进行了重大改进。MySQL 5.4支持InnoDB存储引擎扩展至16路x86服务器和64路CMT服务器,同时也优化了子查询和JION功能,将对特定查询的响应速度提升了90%,这些性能和可伸缩性的提升非常明显,而且不需使用额外应用程序或SQL代码。Sun软件架构和MySQL团队副总裁Karen Tegan Padir在大会的主题演讲时表示:“不需要对应用程序进行任何修改,MySQL 5.4将显著提高它们的性能和可伸缩性,MySQL 5.4也更加适用于扩展SMP系统上的部署。”MySQL 5.4新增功能和性能提升:1、可伸缩性提升:支持InnoDB存储引擎扩展至16路x86服务器和64路CMT服务器,性能提升了一倍;2、子查询优化:提高了分析查询操作的性能,相比之前版本,子查询执行时间缩短;3、新的查询运算法则:利用主存加快多路连接尤其是MySQL集群的执行速度;4、改进了存储过程:增强了SIGNAL/RESIGNAL功能的错误管理能力,应用程序可以更轻松地依赖商业逻辑的存储过程;5、完善了prepared statements:prepared statements中新增了对输出参数的支持;6、改善了信息数据库:为存储过程提供了更多的元数据存取方式,开发人员在使用ODBC和JDBC之类的连接器时可以获取更多的信息;7、改进了对DTrace的支持:提高了Solaris操作系统上的MySQL的诊断和故障排除能力。支持平台:MySQL 5.4适用于多种硬件和软件平台,包括:红帽企业版Linux(RHEL)、Novell的SuSE Enterprise Linux、微软的Windows、Sun的Solaris 10、苹果的Mac OS X、Free BSD、HP-UX、IBM AIX、IBM i5/OS和其他Linux发行版本。目前MySQl 5.4技术预览版本仅支持64位Linux和Solaris 10系统,正式版本将在今年晚些时候发布。官方下载: http://dev.mysql.com/downloads/mysql/5.4.html
2011年07月05日
11 阅读
0 评论
0 点赞
2011-07-05
IBM推出软件开发人员SNS站点My developerWorks
据国外媒体报道报道,IBM推出面向软件开发人员社交网站。对软件开发人员而言,IBM的developerWorks是全球最大的在线技术来源,developerWorks用户约有800万人,占全球软件开发人员的一半。今天,IBM为这些软件开发人员推出了专门的社交网站My developerWorks。My developerWorks与Facebook、LinkedIn或者其他所有我们知道的社交网站都不一样,该社交网站主要聚焦于技术的讨论。在My developerWorks上,全球范围的技术人员可以寻找特定的知识或技能,利用该社交网站的群组、讨论主题和个人资料来判断谁是某一特定领域的专 家。My developerWorks最令人兴奋的前景是不断合作的可能性。IBM所要做的就是如何展示这些技术人员的个人资料,让业务开发、营销、设计、管理和风投人员找到需要的技术人员。那么,初创公司就会不停地出现。一位IBM代表周三晚间通过电子邮件表示:“IBM的目标是,利用My developerWorks,将全球范围的软件开发人员联系起来,让他们在Java、Linux和XML等开放标准的基础上能更容易地进行技术创新。 IBM希望软件开发人员能在分析、清洁技术和云计算等热门技术领域占有一席之地。”那么,为软件开发人员推出专门的社交网站能给IBM带来什么好处?目前还没有关于这方面的评论,不过参与My developerWorks的个人和组织都会获利。
2011年07月05日
7 阅读
0 评论
0 点赞
2011-07-04
动态基础架构 帮助构建“智慧的地球”
世界正在变得更小、更扁平—但也必须变得更智能。每天,世界都变得更加仪器化、互连和智能化,从而在社会和组织层面都创造了新的机遇。在这个日益数字化的世界中,我们可以解决棘手的问题,使企业更加靠近客户,并且显著缩短决策周期,帮助高级主管实现竞争优势。当前的企业面临的主要挑战是:• 实现卓越的区别化服务交付• 降低成本,并且提高所有业务资产的投资回报• 管理并控制业务风险• 敏捷且快速地采取行动应对任何一项挑战—更不必说应对所有挑战—都要求企业的底层业务和IT基础设施具有极高的灵活性和响应能力。但是,当前基础设施中的许多资产缺乏弹性、处于孤立状态,并且过时,导致成本和复杂性高得难以承受,同时阻碍企业的灵活运作。当前的基础设施并未做好应对未来挑战的准备。对于许多企业来说—变革势在必行。变革可能实现,工具已经存在,而且任务已经明确。这些对于解决当前的问题是必要的条件,但不是充分条件—我们还必须抓住未来的机遇。为了实现这两方面的目标,现在我们应该开始以不同的方式来思考基础设施。IBM已经制订出了针对动态基础架构的战略,将帮助企业满足客户对服务的更高期望,解决居高不下的成本压力以及新的风险和威胁,同时为实现突破性的生产力、更快地创造价值以及更高的响应速度奠定基础,从而实现企业和社会所要求的更快速度。在这个智能的世界中,我们的基础设施需要促进我们的发展,而不能阻碍发展。这样的基础设施正变得仪器化、互连和智能化,从而将业务和IT基础设施结合在一起,为企业创造新的机遇。
2011年07月04日
12 阅读
0 评论
0 点赞
2011-07-04
linux crontab 计划任务
crontab 定时指定工作2007-11-02 09:24在 FreeBSD 系统中,系统常常会定时执行一行工作,例如,每天的系统信息统计、系统安全检查等。而系统管理者及一般使用者也可以设定定时执行一些工作,这些工作可以时只执行一次、或是定时重复执行。如果是要设定只执行一次的工作,例如,设定在今天 10:00 时执行某个指令,我们可以使用「at」这个指令。如果是要设定重复报行的工作,例如,设定每天 12 点执行某个指令,我们可以使用「crontab」这个指令,或者是由系统管理者编辑 /etc/crontab 这个档案来进行设定。我们先来看看「crontab」重复定时执行程序的说明:「crontab」重复定时执行程序在 UNIX 系统中,有一个背景程序会定时执行一些工作,这个程序在 FreeBSD 中称为「cron」。「cron」这个程序会定时去检查 /etc/crontab 及 /var/cron/tabs 中的档案,并执行其中的设定。/etc/crontab 可以让管理者设定要以什么使用者的身份去执行定时工作,而一般使用者如果要设定定时执行工作时,可以使用指令 crontab -e 来编辑自己的定时执行工作,crontab 会将使用者的工作设定放在 /var/cron/tabs 中。我们先来看一下 /etc/crontab 的内容说明:# 设定使用的 shell, 路径 SHELL=/bin/sh PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin # 设定执行指令时的目录 HOME=/var/log # 当指令有输出数据时,要将输出的东西寄给谁。 MAILTO="" # # 分 小时 天 月 星期几 身份 指令 #minute hour mday month wday who command # */5 * * * * root /usr/libexec/atrunminute:代表一小时内的第几分,范围 0-59。 hour:代表一天中的第几小时,范围 0-23。 mday:代表一个月中的第几天,范围 1-31。 month:代表一年中第几个月,范围 1-12。 wday:代表星期几,范围 0-7 (0及7都是星期天)。 who:要使用什么身份执行该指令,当您使用 crontab -e 时,不必加此字段。 command:所要执行的指令。 小时的字段中如果是 *,表示每小时,天的字段中如果是 *,表示每天,依此类推。字段中也可以使用 "-" 来表示范围。例如,在小时的字段中填 8-11,表示执行的时间是 8,9,10,11,共四次。字段中也可以用逗点来表示,以分的字段而言, 1,2,5,9 表示将在 1,2,5,9 分时各执行一次。我们也可以写成像这样 1-2,12-14 ,表示在 1,2,12,13,14 分各执行一次。另外,也可以用 / 后面加数字表示每几分钟要执行一次。如在分的字段填 0-23/2,表示 1-22 分之间,每隔二分钟执行一次,也就是 0,2,4,6,8,10,12,14,16,18,20,22。如果在分的字段是 */5,表示每五分钟一次。除此之外,在时间的字段中,我们也可以用一个开头为 @ 的字符串来表示各种排程时间意义:字符串 代表意义 @reboot 开机时跑一次。 @yearly 每年跑一次,等于 "0 0 1 1 *"。 @annually 和 @yearly 一样。 @monthly 每月跑一次,等于 "0 0 1 * *",也就是每月一日半夜 12 点执行。 @weekly 每周跑一次,等于 "0 0 * * 0",也就是每个周日半夜 12 点执行。 @daily 每天跑一次,等于 "0 0 * * *",也就是每天半夜 12 点执行。 @midnight 和 @daily 一样。 @hourly 每小时跑一次,等于 "0 * * * *"。另外,我们还可以在档案中以「key = value」的方式设定在执行指令时的环境变量。例如,一般指令有输出执行结果时,会自动寄给 root,我们也可以设定「MAILTO = ""」表示不要将输出结果寄出。以下为几个时间设定的范例:# 分 小时 天 月 星期几 身份 指令 #minute hour mday month wday who command # # 设定每 5 分钟执行一次atrun。 */5 * * * * root /usr/libexec/atrun# 设定每天一点零一分时执行 /bin/check 1 1 * * * root /bin/check# 设定每周一 3:11 分执行 week_check 11 3 * * 1 root /usr/local/week_check# 设定每天一点及四点的零到二十三分中间,每二分钟执行一次 something。 0-23/2 1,4 * * root /bin/something# 设定每天半夜十二点执行 something。 @daily root /bin/something如果你以一般使用者或是管理者的身份执行 crontab -e 来设定 crontab,你不必设定身份的字段,因为 crontab 会自动取得您的身份。使用 crontab -e 所设定的工作会被放在 /var/cron/tabs 目录中,所以如果要备份或升级时,应该要注意这些档案是否要备份。小提示 我们在安排 crontab 时,应该要错开每个程序的执行时间,才不会有一大堆程序同时执行,造成系统负荷过高。「at」设定只执行一次的程序cron 可以用来设定不断的重复定时执行一些工作,然而,如果您只希望在某个时间执行「一次」某个指令,可以使用「at」。「at」的设定可以分为三个指令:「at」用来建立工作、「atq」用来列出目前待执行的工作有哪些、「atrm」用来删除 atq 中所列出的工作。当您执行了 at 后,它会要求您在命令列中以 shell scripts 的写法输入想要执行的指令,而您也可以先将所要执行的指令写再一个档案中,再让 at 去执行。在使用 at 指令时,必须先输入您要在什么时候执行工作,而时间的格式可以是下列任何一种:格式 说明 at 10pm 设定晚上十点执行。时间的格式可以是 HHMM 或 HH:MM。 at 8:30am Oct 10 设定十月十日早上八点半执行。 at midnight Jan 1 2005 设定 2005 年一月一日的第一秒钟执行。 at teatime 设定在下次的下午 4 点执行。teatime 表示是 4:00pm,而 midnight 表示半夜十二点,noon 表示中午十二点。 at -t MMDDhhmm 表示在 MM 月 DD 日 hh 时 mm 分时执行,您还可以在 MM 前加上年,而年的格式二位或是四位都可以。如果您要设定在 10pm 执行某些工作,您可以打「at 10pm」后按 <Enter>,接着您必须开始输入所要执行的指令,在全部输入完成后,请按 <Ctrl>+<D>结束编辑。如果您不想使用命令列编辑的方式输入所要执行的工作,您可以先写一个 shell script 并使用下列指令设定:# at -f mycommand.sh 10pm 上述指令中,您所写的 shell scripts 档案是 mycommand.sh。在设定之后,接着您可以使用下列指令列出目前等待执行的 at 工作:# atq Date Owner Queue Job# 2005年 6月 5日 周日 22时00分00秒 CST root c 2 如果您要删除某一个工作,只要使用 atrm 并输入该工作在 atq 中的 job id 即可。例如,我们要删除 ID 为 2 的工作:# atrm 2 限制一般使用者使用 cron 及 at大部份的情况下,一般使用者应该不会需要使用定时排程的工作。如果您发现有使用者定时会执行一些耗费系统数据的工作,我们可以为这个指令设限,只允许必要的使用者执行。如果要限制使用 crontab,只需要在 /var/cron 目录中,加入 allow 或是 deny 这个档即可。例如,我们只允许少数几个使用者执行 crontab,我们可以新增 /var/cron/allow 这个档,内容为该使用者的名称。相对的,如果我们要限制少数几个使用者执行 crontab,只要编辑 /var/cron/deny 这个档即可。而指令 at 的限制也是一样,不同的只是允许执行 at 指令的名单是 /var/at/at.allow,而拒绝的名单是 /var/at/at.deny。 crontab命令使用2007年05月14日 星期一 上午 10:06 名称 : crontab 使用权限 : 所有使用者 使用方式 : crontab [ -u user ] file crontab [ -u user ] { -l | -r | -e } 说明 : crontab 是用来让使用者在固定时间或固定间隔执行程序之用,换句话说,也就是类似使用者的时程表。-u user 是指设定指定 user 的时程表,这个前提是你必须要有其权限(比如说是 root)才能够指定他人的时程表。如果不使用 -u user 的话,就是表示设定自己的时程表。 参数 : crontab -e : 执行文字编辑器来设定时程表,内定的文字编辑器是 VI,如果你想用别的文字编辑器,则请先设定 VISUAL 环境变数来指定使用那个文字编辑器(比如说 setenv VISUAL joe) crontab -r : 删除目前的时程表 crontab -l : 列出目前的时程表 crontab file [-u user]-用指定的文件替代目前的crontab。 时程表的格式如下 : f1 f2 f3 f4 f5 program 其中 f1 是表示分钟,f2 表示小时,f3 表示一个月份中的第几日,f4 表示月份,f5 表示一个星期中的第几天。program 表示要执行的程序。 当 f1 为 * 时表示每分钟都要执行 program,f2 为 * 时表示每小时都要执行程序,其馀类推 当 f1 为 a-b 时表示从第 a 分钟到第 b 分钟这段时间内要执行,f2 为 a-b 时表示从第 a 到第 b 小时都要执行,其馀类推 当 f1 为 */n 时表示每 n 分钟个时间间隔执行一次,f2 为 */n 表示每 n 小时个时间间隔执行一次,其馀类推 当 f1 为 a, b, c,... 时表示第 a, b, c,... 分钟要执行,f2 为 a, b, c,... 时表示第 a, b, c...个小时要执行,其馀类推 使用者也可以将所有的设定先存放在档案 file 中,用 crontab file 的方式来设定时程表。例子1 : #每天早上7点执行一次 /bin/ls : 0 7 * * * /bin/ls 在 12 月内, 每天的早上 6 点到 12 点中,每隔3个小时执行一次 /usr/bin/backup : 0 6-12/3 * 12 * /usr/bin/backup 周一到周五每天下午 5:00 寄一封信给 alex@domain.name : 0 17 * * 1-5 mail -s "hi" alex@domain.name < /tmp/maildata 每月每天的午夜 0 点 20 分, 2 点 20 分, 4 点 20 分....执行 echo "haha" 20 0-23/2 * * * echo "haha" 注意 : 当程序在你所指定的时间执行后,系统会寄一封信给你,显示该程序执行的内容,若是你不希望收到这样的信,请在每一行空一格之后加上 > /dev/null 2>&1 即可例子2 : #每天早上6点10分 10 6 * * * date #每两个小时 0 */2 * * * date #晚上11点到早上8点之间每两个小时,早上8点 0 23-7/2,8 * * * date #每个月的4号和每个礼拜的礼拜一到礼拜三的早上11点 0 11 4 * mon-wed date #1月份日早上4点 0 4 1 jan * datelinux下开机自动运行怎么设定啊crontab* * * * * scriptsname前面是时间 后面是脚本名
2011年07月04日
10 阅读
0 评论
0 点赞
2011-07-04
How Secure Are Query Strings Over HTTPS?
A common question we hear is “Can parameters be safely passed in URLs to secure web sites? ” The question often arises after a customer has looked at an HTTPS request in HttpWatch and wondered who else can see this data.For example, let’s pretend to pass a password in a query string parameter using the following secure URL:https://www.httpwatch.com/?password=mypasswordHttpWatch is able to show the contents of a secure request because it is integrated with the browser and can view the data before it is encrypted by the SSL connection used for HTTPS requests:If you look in a network sniffer, like Network Monitor, at the same request you would just see the encrypted data going backwards and forwards. No URLs, headers or content is visible in the packet trace::You can rely on an HTTPS request being secure so long as: No SSL certificate warnings were ignored The private key used by the web server to initiate the SSL connection is not available outside of the web server itself. So at the network level, URL parameters are secure, but there are some other ways in which URL based data can leak: URLs are stored in web server logs- typically the whole URL of each request is stored in a server log. This means that any sensitive data in the URL (e.g. a password) is being saved in clear text on the server. Here’s the entry that was stored in the httpwatch.com server log when a query string was used to send a password over HTTPS:2009-02-20 10:18:27 W3SVC4326 WWW 208.101.31.210 GET /Default.htm password=mypassword 443 ...It’s generally agreed that storing clear text passwords is never a good idea even on the server. URLs are stored in the browser history – browsers save URL parameters in their history even if the secure pages themselves are not cached. Here’s the IE history displaying the URLparameter:Query string parameters will also be stored if the user creates a bookmark. URLs are passed in Referrer headers – if a secure page uses resources, such as javascript, images or analytics services, the URL is passed in the Referrer request header of each embedded request. Sometimes the query string parameters may be delivered to and stored by third party sites. In HttpWatch you can see that our password query string parameter is being sent across to Google Analytics: ConclusionThe solution to this problem requires two steps: Only pass around sensitive data if absolutely necessary. Once a user is authenticated it is best to identify them with a session ID that has a limited lifetime. Use non-persistent, session level cookies to hold session IDs and other private data. The advantage of using session level cookies to carry this information is that: They are not stored in the browsers history or on the disk They are usually not stored in server logs They are not passed to embedded resources such as images or javascript libraries They only apply to the domain and path for which they were issued Here’s an example of the ASP.NET session cookie that is used in our online store to identity a user:Notice that the cookie is limited to the domain store.httpwatch.com and it expires at the end of the browser session (i.e. it is not stored to disk).You can of course use query string parameters with HTTPS, but don’t use them for anything that could present a security problem. For example, you could safely use them to identity part numbers or types of display like ‘accountview’ or ‘printpage’, but don’t use them for passwords, credit card numbers or other pieces of information that should not be publicly available.
2011年07月04日
11 阅读
0 评论
0 点赞
2011-07-03
闲谈 Web 图片服务器
现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片,如果前期没有很好的规划,那么随着图片文件的增多,无论是管理还是性能上都带来很多问题。就自己的一点理解,抛砖引玉,以期能引出更具价值的信息。事关图片的存储把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备,那么简单的很;如果有能力自己开发单独存储图片的文件系统,那么也不用接着往下看了。如果上述条件不具备,只想在普通的硬盘上存储,首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的,实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ,怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑,选择合适大小的 inode size ,在空间和速度上做取舍,同时防患于未然,注意单个文件系统下文件个数别达到极限。独立,独立的服务器无论从管理上,还是从性能上看,只要有可能,尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后,在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。如果不想在几台机器间同步所有图片,只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题,以及 NFS 特定的传输速度。独立,独立的域名如果大部分 Web 页面必须要载入很多图片,那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。前几天有个朋友在线上问我,”一些大网站,图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ,粗糙一点的答案:除了管理方便,便于CDN 同步处理,上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知,有请 Yahoo!的同学发言) 【还有一个我没考虑到的是 Cookie 的因素,参加楼下高春辉的留言】雅虎 Web 优化 14 条关于雅虎 YSlow 工具倡导的优化 14 条规则,建议每个 Web 维护人员必须倒背如流,当然也应该辩证来看–介绍这 14 条规则的页面本身也只能得到 70 多分…其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。有效利用客户端 Cache很多网站的 UI 设计人员为了达到某些视觉效果,会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况,研究表明,对于用户粘度比较高的站点, 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的,大量带宽就这么节省下来,费用也节省了下来。顺便说一下,对于验证码这样的东西,要加个简单的规则过滤掉。服务器端的 Cache在国内,CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务,国内还没有出现。所以,充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器,缓冲图片效果应该说尚可,新浪技术团队贡献的 Ncache 据评测,效果更佳。高解析图片问题如果网站存在大量高解析度的图片,那么有必要考虑部署 IIPImage 或者类似的软件。运营问题很多比较有规模的网站对于用户上传的图片不做任何处理,结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)…这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块,对那些”截屏”得来的图片做个转换,投入成本可能远比存储上的开销小,而用户再访问该图片,质量未必能有什么损失,浏览速度无疑好多了。哪种处理方式更让人接受,不言而喻。FROM:http://www.dbanotes.net/web/web_image_server.html
2011年07月03日
9 阅读
0 评论
0 点赞
2011-07-02
推荐《构建可扩展的Web站点》
又名: Build Scalable Web Sites作者: Cal Henderson译者: 徐宁ISBN: 9787121060793页数: 330定价: 58.0出版社: 电子工业出版社装帧: 平装出版年: 2008简介 市场价: 58.0 卓越价: 49.3 到卓越购买随着Web 2.0网站的蓬勃发展,如何成功地构建可扩展的Web站点成为网站开发人员必备的技能。本书是Flickr.com的主力开发人员讲解构建可扩展的Web 站点的经典之作。本书主要介绍了Web应用程序的概念、体系结构、硬件需求、开发环境的原则及国际化、本地化和Unicode等基本内容,并为解决Web 应用程序的数据安全、电子邮件整合、远程服务交互、应用程序优化、扩展、监测和预警、开放API等问题提供了很多简单实用的技巧和方法。本书涉及的内容十分广博,但核心相当明确,即如何构建安全的、用户喜爱的、可以不断扩展的Web应用程序。任何从事Web应用程序开发的读者都会从中获益匪浅。作者简介Cal Henderson来自英格兰, 是照片共享服务Flickr的工程经理, 目前在美国加州森尼维耳市的Yahoo!公司工作. 在创建Flickr应用程序之前, CalcHenderson在英国一家媒体公司Emap担任一个特殊Web项目的技术主管.
2011年07月02日
7 阅读
0 评论
0 点赞
1
...
4
5
6