lyflower的专栏

转如何进行Lucene的分布式应用

lyflower — Thu, 21 Apr 2011 17:38:00 +0800

研讨如何进行Lucene的分布式应用
共1页

　　提问：
　　现在有个项目，有10台服务器，每台服务器负责某一部分的index。另外有一台web服务器，它可以根据用户提交的查询请求到特定的服务器上进行查找。比如用户提交查询A，根据index的分配情况，可以将查询请求分发给服务器a来负责，而用户提交查询请求B，则将它提交给服务器b来负责。不知lucene目前的index机制和search机制是否能够支持这种需求？

回答：
　　1. 目前lucene的机制不支持这种需求
　　2. 你可以很容易的扩展lucene,从而满足你的需求.
　　实际上,你这是涉及到 indexing的分布式存储的问题, 涉及到结构, 传输,等等.
　　所以,你必须要设计一个robust的分布式index结构,然后再考虑如何实现.不要一开始就拿一个开源的lucene就上.
　　google当然是分布式的索引. 只不过这个分布式可能不是你想象中的那么神秘.

关于搜索引擎及其开发

lyflower — Wed, 23 Mar 2011 17:07:00 +0800

托google、百度们成功的福，搜索引擎火了半边天。很多人都想跨到这个行业里边来。前两天在公司里边面试了一些人，基本上没有感到满意。不是说从业经验不够，有些也已经工作了三年、四年。不过我估计，或者说是猜想，是不是做应用做的时间太长了，把数据结构、算法，时间、效率都扔到一边去了；然后平时的工作又太忙，平时自己工作的做的可以，但对工作相关的、稍微扩展的知识没有时间或者说是懒得去看了。。。。。
我的想法是，如果有兄弟姐妹要进入这个行业，最好对这个行业流行的想法、做法了解一些，如果不了解这些，就把数据结构和算法的基础课好好看看，或者说好好练练编程的基本功。搜索引擎开发涉及到了我们上学时学到的所有的东西。而且有些特别新的东西是没有书可以看得，有的只是经验，经过传承到了后进入者的手里；好的话，就是有论文，不过有价值的都是英文论文，国内的都是抄来抄去，不如直接去看他的原文（比如，也不知道哪个神仙把robust翻译成鲁棒性，放着健壮性之类的已经有的好词不用，非得翻译成这么一个上下不着地的词，而且现在还有逐渐流行的趋势。。。。）。不过，有本书叫做

Memcache基础教程

lyflower — Tue, 22 Mar 2011 17:07:00 +0800

Memcache基础教程
Memcache是什么
Memcache是danga.com的一个项目，最早是为 LiveJournal 服务的，目前全世界不少人使用这个缓存项目来构建自己大负载的网站，来分担数据库的压力。
它可以应对任意多个连接，使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间，然后建立一个HashTable，Memcached自管理这些HashTable。
Memcache官方网站：http://www.danga.com/memcached，更多详细的信息可以来这里了解
为什么会有Memcache和memcached两种名称？
其实Memcache是这个项目的名称，而memcached是它服务器端的主程序文件名，知道我的意思了把~~~~。一个是项目名称，一个是主程序文件名，在网上看到了很多人不明白，于是混用了。
Memcache的安装
分为两个过程：memcache服务器端的安装和memcached客户端的安装。
所谓服务器端的安装就是在服务器（一般都是l

svn 版本控制 trunk branch tag

lyflower — Sat, 26 Feb 2011 10:44:00 +0800

——简单的对比　　SVN的工作机制在某种程度上就像一颗正在生长的树：一颗有树干和许多分支的树分支从树干生长出来，并且细的分支从相对较粗的树干中长出一棵树可以只有树干没有分支（但是这种情况不会持续很久，随着树的成长，肯定会有分支啦，^^）一颗没有树干但是有很多分支的树看起来更像是地板上的一捆树枝如果树干患病了，最终分支也会受到影响，然后整棵树就会死亡如果分支患病了，你可以剪掉它，然后其他分支还会生长出来的哦！如果分支生长太快了，对于树干它可能会非常沉重，最后整棵树会垮塌掉当你感觉你的树、树干或者是分支看起来很漂亮的时候，你可以给它照张相，这样就就可以记得它在那时是多么的赞。——Trunk　　Trunk是放置稳定代码的主要环境，就好像一个汽车工厂，负责将成品的汽车零件组装在一起。　　以下内容将告诉你如何使用SVN trunk：除非你必须处理一些容易且能迅速解决的BUG，或者你必须添加一些无关逻辑的文件（比如媒体文件：图像，视频，CSS等等），否则永远不要在trunk直接做开发不要因为特殊的需求而去对先前的版本做太大的

数据更新快量大的业务设计数据库

lyflower — Tue, 22 Feb 2011 14:35:00 +0800

对于千万到几亿级别的数据
设备id分表，按区段或者取模这种传统手段都可以
时间long型做主键
最后去掉自增列

并发如果超过一定量级（比如每秒100次了）
就开始读写分离
主库无索引只写入
从库建索引调整索引大小

如果超大并发（比如每秒500-1000次及以上写入）就这样子：
原始数据用aof式的log存
然后异步的存入数据库
数据库本身再读写分离
写入log后，多个worker并发的往数据库里面写，近乎于即时了。

说白了，这种规模的系统，关键就是索引
拿关系数据库就个多快好省的索引系统用了

数据归档也是应该做的，冷热数据分离，老数据根据不同维度做一定的合并

linux mysql乱码

lyflower — Tue, 25 Jan 2011 09:43:00 +0800

全部默认utf8
linux终端utf-8
方法一：

LANG="en_US.UTF-8"
SUPPORTED="zh_CN.UTF-8:zh_CN:zh:en_US.UTF-8:en_US:en"
SYSFONT="latarcyrheb-sun16"方法二：vi /etc/profileexport LC_ALL="en_US.UTF-8"mysql vi /etc/my.cnf[client]default-character-set=uft8[mysqld]default-character-set=utf8init_connect='SET NAMES utf8'

使用Java NIO编写高性能的服务器

lyflower — Fri, 21 Jan 2011 19:17:00 +0800

从JDK 1.4开始，Java的标准库中就包含了NIO，即所谓的“New IO”。其中最重要的功能就是提供了“非阻塞”的IO，当然包括了Socket。NonBlocking的IO就是对select(Unix平台下)以及 WaitForMultipleObjects(Windows平台)的封装，提供了高性能、易伸缩的服务架构。说来惭愧，直到JDK1.4才有这种功能，但迟到者不一定没有螃蟹吃，NIO就提供了优秀的面向对象的解决方案，可以很方便地编写高性能的服务器。话说回来，传统的Server/Client实现是基于Thread per request，即服务器为每个客户端请求建立一个线程处理，单独负责处理一个客户的请求。比如像Tomcat（新版本也会提供NIO方案）、Resin等Web服务器就是这样实现的。当然为了减少瞬间峰值问题，服务器一般都使用线程池，规定了同时并发的最大数量，避免了线程的无限增长。但这样有一个问题：如果线程池的大小为100，当有100个用户同时通过HTTP现在一个大文件时，服务器的线程池会用完，因为所有的线程

解决mysql“Access denied for user 'root'@'localhost'”

lyflower — Fri, 14 Jan 2011 00:23:00 +0800

# mysql -uroot -p
Enter password:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

使用网上介绍的方法修改root用户的密码：
# mysqladmin -uroot -p password 'newpassword'
Enter password:
mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'root'@'localhost' (using password: YES)'

现在终于被我找到了解决方法，如下（请先测试方法三，谢谢！）：
方法一：
# /etc/init.d/mysql stop
# mysqld_safe --user=mysql --skip-grant-

消息队列

lyflower — Thu, 30 Dec 2010 10:14:00 +0800

twitter最近将ruby实现的消息队列服务器starling开源了，这是一个支持memcache协议的轻量级持久化服务器，因此使用php/perl/ruby/java等多种客户端都没问题，可以将较慢的处理逻辑通过消息队列放在后台处理，同时也支持多点分布式处理。

利用消息队列可以很好地异步处理数据传送和存储，当你频繁地向数据库中插入数据、频繁地向搜索引擎提交数据，就可采取消息队列来异步插入。另外，还可以将较慢的处理逻辑、有并发数量限制的处理逻辑，通过消息队列放在后台处理，例如FLV视频转换、发送手机短信、发送电子邮件等。

memcacheq是持久化的队列系统:
http://code.google.com/p/memcacheq
memqd是一个内存化的队列系统:
http://code.google.com/p/memqd

HTTPSQS（HTTP Simple Queue Service）是一款基于 HTTP GET/POST 协议的轻量级

Twitter架构图(cache篇)

lyflower — Wed, 29 Dec 2010 16:51:00 +0800

根据网上公开资料整理的Twitter架构，主要是cache方面，加了作者自己的补充，跟实际的架构未必完全一致。

一些数据：Cache分Page cache, fragment cache, row cache, vector Cache, cache命中率见图。Fragment cache存放了API各种请求格式的数据，包括XML, JSON, RSS, ATOM。发表Tweets是先放入Kestrel, 再异步处理，Kestrel用的也是memcached协议。API requests: 550 r/s。POST tweets: 峰值：平时 80tweets/s, 奥巴马就任时达到 350tweets/s。Aggregator模块需要访问memcached multi get 数百个/s。Ruby on Rails前面还用了Varnish作前端反向代理。
参考资料：QCon London 2009: Upgrading Twitter without service disruptionsImproving Running C