#
摘要: Chili ProjectOmnigroupPaymoSpringloopsComindworkWebprojectorSoloOpen AtriumCaseboxRedboothAgilezenProducteevRedmineApollohqCentral DesktopRationalplanTeamworkTeamlabFastdueFreedcampHuddleIssue BurnerN...
阅读全文
摘要: 用途及用法 网络请求通常有两种形式：第一种，请求不是很频繁，而且每次连接后会保持相当一段时间来读数据或者写数据，最后断开，如文件下载，网络流媒体等。另一种形式是请求频繁，但是连接上以后读/写很少量的数据就断开连接。考虑到服务的并发问题，如果每个请求来到以后服务都为它启动一个线程，那么这对服务的资源可能会造成很大的浪费，特别是第二种情况。因为通常情...
阅读全文
回想起来，我也算是国内接触推荐系统较早的人之一了，最近和人聊天，觉得不少人对推荐系统有所误解，以为需要多么高大上的算法才能搭建起来的，我只想说我经常说的那句话【不是这样的】，所以有了这篇文章。
第一次接触【推荐系统】是在两年前在某高校的互联网信息处理实验室的时候，那时候，【机器学习】和【大数据】都是新概念，但是差不多半年后，【大数据】的概念就开始风靡全球了，到现在已经被爆炒得面目全非。
那年还因此买了一本项亮的书《推荐系统实践》，那本书和现在的很多热门书籍一样，都是跟着概念热起来的。 虽然有一些作者自己的实战经验在里面，但是总体上来说并没有太多值得重复翻开的地方。
几乎所有宣扬【推荐系统】的人，都要拿【啤酒和尿布】，【亚马逊推荐占营收20%】之类的经典例子来说力证推荐系统的牛逼之处。到处宣扬【推荐系统】插上【机器学习】等算法的翅膀，就能让电子商务变得精准无比，能智能的猜出用户想买的东西。
殊不知，其实这两个例子和所谓的【算法】其实关系不大。
1. 啤酒和尿布 首先是【啤酒和尿布】，超市的人员发现买啤酒的男人容易顺手买尿布。这其实是一种数据分析，是根据数据统计加上人工分析得出，是一种以经验来改善销售的行为。和【机器学习】【数据挖掘】等算法的关系不大。 刚接触【推荐系统】的时候，【协同过滤算法】大热， 我也曾经迷恋得研究过该算法，以为发现了什么宝贝一样。但是实际上，在工程中【协同过滤】出来的效果往往惨不忍睹，所谓的【算法工程师】每天能做的就是在那调整【协同过滤】算法的相关参数，然后看看第二天的点击率有没有上升。然后调整到最后你会发现，牛逼哄哄的【协同过滤】其实还不如简简单单的【看了又看】效果来的好，虽然协同过滤算法本质上也是一种【看了又看】的思想。
2. 亚马逊的推荐系统 亚马逊的推荐系统占了营收比，我记得是20%，不知道现在上升了还是下降了。这个说辞会让很多人误以为只要你搞好了推荐系统，你的营收就能上升20%以上一样。其实不然，对于亚马逊来说，为什么推荐能起到这么高的销量，一个很重要的原因在于，【亚马逊的首页点击率高的部分位置划分给了推荐系统的】，从广告学上讲，广告位置的好坏极大的决定了广告的销量。这个很容易理解，假设你的产品的广告牌能挂上天安门城楼的话，你觉得你还需要担心该产品的销量吗？
当然不可否定的是亚马逊的推荐系统应该是很牛逼的，但是这并不说明他们采用的【推荐算法】非常牛逼。推荐系统我认为其实和搜索系统并无太大差异，我一直认为推荐系统其实只是一个个性化的搜索引擎。之前在【秘密】上很火的有个爆料是：“360搜索的Rank刚开始就是用【机器学习】的算法去做，屎一样的效果，是我把百度的基于规则的算法偷过去之后才变好的。” ，这个爆料出来不少人讽刺【基于规则】，觉得这是在黑百度的算法。 其实不是这样的，记得当时阿里搜索挖了一个谷歌搜索的员工，该人在阿里分享的时候就说过：【谷歌的搜索效果比别人好的原因就是规则库牛逼，关于算法使用的都是成熟的人尽皆知的算法，并没什么新奇酷的算法】。 可能也是这个原因，谷歌研究院的科学家几乎全是【工程师背景】出身的。还记得上次【CCF推荐系统前言讲座】，刚开始叫了几个学院派的讲师在那大讲特讲各种酷炫掉渣天的算法，然后淘宝的大数据负责人车品觉 上台之后直接来了句【我们实验出各种算法效果不太好，还不如最基本的 关联规则效果来的好】直接把前面的学院派专家们打脸打得都肿了。
我心目中的推荐系统 不管是电商，或者是新闻，都有【个性化推荐】和【热门推荐】的取舍。一个商品热门或者点击量高是有其原因的。所以将热门的东西推荐给用户是非常合情合理的，因为既然热门，也侧面说明了很大概率上该用户也会喜欢该商品。而【个性化推荐】本质上是为了解决【长尾】问题，把那些不热门的东西，但是很可能符合某特定用户品味的商品【挖掘】出来，推荐给特定的用户群。
首先，在推荐中，醒目的推荐位应该是【热门推荐】或者【人工推荐】，【人工推荐】是指比如在体育新闻中，巴萨夺冠之类的大新闻是直接让编辑来【人工推荐】即可，就是此新闻一出，马上登上头条，而不是在那磨磨唧唧的计算特征值，计算相似度，计算是否符合用户兴趣。 对于推荐中的【冷启动】，最理想的推荐就是【相关推荐】。说到这里，整个推荐系统的 80% 已经搭建完毕，【热门推荐+人工推荐+相关推荐】，这三者都是【个性化】都没什么关系，也算法关系也不大，但是这三者效果的好坏就决定了整个系统推荐效果好坏的 80% 。好多人连最基本的这三者都没有做好，就开始想一步登天，很可惜，这样的捷径是不存在的。 接下来是 20% 的【个性化】的做法，如上所说，个性化是为了解决【长尾】问题，正是因为长尾占商品的 20% ，所以在此我认为【个性化】其实也只有 20% 。要解决个性化，首先就是要对用户分析，最成熟的办法就是对用户打标签（是否让你想起来社交网络为什么经常让你选用合适的标签描述自己，没错，就是为了分析你）。
其实，给用户打标签，逼格更高的说法叫【用户特征提取】或者【用户行为分析】。说到这两个词，那些所谓的算法工程师可能就会开始扯什么高大上的算法，机器学习，自然语言处理，数据挖掘等各种算法。其实在我看来，算法很大情况根本派不上用场，我认为这方面的关键在于【数据统计 + 人工分析】。将用户的浏览记录等记录下来，统计他最常点击的东西，最常去的频道，然后给他打上这些频道或者商品的标签。或者收集更详细的信息，比如年龄，打上【青少年，男人，女人，老人】等标签，根据这些标签进行推荐。比如当推荐护肤的商品时，就可以偏向于女人，推荐运动产品时，就可以偏向于男人和青少年，推荐保健品时，就可以偏向于老年人。所以，光看年龄这个标签的维度，就可以做很多文章。所以标签库的设计和积累，是非常广泛和重要的，而这方面需要大量依赖于【人工分析】，而不是看论文调算法能做到的。 就好比现在的中文分词，拼到最后大家都在比词库的积累，谁的词库好，谁的效果就好，【搜狗】的【拼音输入法】效果好也是因为词库比别人好。
最后就是根据标签的定向推荐，这个推荐概率是有【权重设置】在里面，就比如刚才对年龄这个维度的权重，是需要给予对应的权重值，如何给定呢？其实就是【拍脑袋】，当然，如果有某些公司已经得出经验值了直接可以拿来用就会更好。但是在拍完脑袋之后需要做的就是观察点击率变化，查Bad Case，然后再对权重进行调整，也就是根据评测和反馈来调整，没有【评测和反馈】，整个系统等于是一个黑盒，谈何优化？在我看来，【推荐系统】本质上首先是一个系统，需要不断的对各种效果进行【评测】，查各种【Bad Case】，而这些都不是看论文可以学到的东西。
总结 1、实力派的【算法工程师】往往都是ABC[always be coding]，这样的算法工程师才能根据实际问题建立模型或者建立规则库，是真正能解决问题的人。往往是一些有研究背景，经验丰富的研究员，更加重视工程，因为工程架构上一些恰当合理的设计，效果往往就能远远高过于模型算法优化。
2、学院派的【算法工程师】往往是为了算法而算法，而不是为了解决推荐系统的问题去找最适合算法。这也是为什么大公司经常招了一些博士毕业的算法工程师后，不是研究算法而是让他们整天在那看数据报表？【因为发现算法没啥好研究，只能让他们在那看看报表找找规律了。】
3、【几乎所有所谓的智能推荐算法都是花拳绣腿】
4、当一个做推荐系统的部门开始重视【数据清理，数据标柱，效果评测，数据统计，数据分析】这些所谓的脏活累活，这样的推荐系统才会有救。
策略模式：
场景：又称警察模式，假设小明开快车，遇到警察，可能是好警察，只是口头警告一下，就让小明走了，也可能是强硬的警察，给小明开了罚单。但小明是不知道到底会遇到哪种警察，要到RUNTIME的时候才知道。
不好的封装：将好警察的处罚行为封装为一个类A，将强硬警察的处罚行为封装为另一个类B，将判断如何处罚封装成一个类C，在这个类中判断类的类型，如果是A类，则执行A方法，如果是B类，则执行B方法。
良好的封装：将警察的处罚行为统一为一个接口I-A的一个方法，类C的执行方法只传入接口I-A。
传统MySQL+ Memcached架构遇到的问题
实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题：
MySQL需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。
Memcached与MySQL数据库数据一致性问题。
Memcached数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。
跨机房cache同步问题。
众多NoSQL百花齐放，如何选择
最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问 题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决 以下几种问题
少量数据存储，高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。
海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。
这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过 类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。
Schema free，auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。
面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。
Redis适用场景，如何正确的使用
前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed 的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用 Memcached,何时使用Redis呢？
Redis与Memcached的比较
网络IO模型
Memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程，监听线程监听网络连接，接受请求后，将连接 描述字pipe 传递给worker线程，进行读写IO, 网络层使用libevent封装的事件库，多线程模型可以发挥多核作用，但是引入了cache coherency和锁的问题，比如，Memcached最常用的stats 命令，实际Memcached所有操作都要对这个全局变量加锁，进行计数等工作，带来了性能损耗。
（Memcached网络IO模型）
Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和 select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操 作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。
内存管理方面
Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存 储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费，并且在内存仍然有很大空间时，新的数 据也可能会被剔除，原因可以参考Timyang的文章：http://timyang.net/data/Memcached-lru-evictions/
Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎 片，Redis跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致 swap也不会剔除任何非临时数据（但会尝试剔除部分临时数据），这点上Redis更适合作为存储而不是cache。
数据一致性问题
Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断。
存储方式及其它方面
Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能
Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS
进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能。
关于不同语言的客户端支持
在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一 些，目前看在客户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新 的功能等，对应第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。
根据以上比较不难看出，当我们不希望数据被踢出，或者需要除key/value之外的更多数据类型时，或者需要落地功能时，使用Redis比使用Memcached更合适。
关于Redis的一些周边功能
Redis除了作为存储之外还提供了一些其它方面的功能，比如聚合计算、pubsub、scripting等，对于此类功能需要了解其实现原理，清 楚地了解到它的局限性后，才能正确的使用，比如pubsub功能，这个实际是没有任何持久化支持的，消费方连接闪断或重连之间过来的消息是会全部丢失的， 又比如聚合计算和scripting等功能受Redis单线程模型所限，是不可能达到很高的吞吐量的，需要谨慎使用。
总的来说Redis作者是一位非常勤奋的开发者，可以经常看到作者在尝试着各种不同的新鲜想法和思路，针对这些方面的功能就要求我们需要深入了解后再使用。
总结：
Redis使用最佳方式是全部数据in-memory。
Redis更多场景是作为Memcached的替代者来使用。
当需要除key/value之外的更多数据类型支持时，使用Redis更合适。
当存储的数据不能被剔除时，使用Redis更合适。
后续关于Redis文章计划：
Redis数据类型与容量规划。
如何根据业务场景搭建稳定，可靠，可扩展的Redis集群。
Redis参数，代码优化及二次开发基础实践。
关于作者
田琪，目前负责新浪微博平台底层架构与研发工作，之前曾担任搜狐白社会实时游戏平台核心架构工作，主要关注webgame, 分布式存储，nosql 和 erlang 等领域，目前主要从事mysql源代码的一些深入研究工作，浪微博：http://weibo.com/bachmozart。
摘要: 简单来说，观察者模式=发布者+订阅者。下面是一个有关猎头的典型的例子。在下面这张图当中有两个角色：猎头和寻找工作的人。找工作的人向猎头订阅，告知自己希望得到一份工作，当有新的工作机会的时候，猎头就会把这个信息通知给曾经向他订阅过的人。Java代码Subject接口：1public interface Subject {2 publi...
阅读全文
$('#formID').on('submit',function () {
$.ajax({
url: 'submit.php',
cache: false,
type: 'POST',
data : $('#formID').serialize(),
success: function(json) {
alert('all done');
}
});
});
-----------------曾国藩箴言（一）----------------
●轻财足以聚人，律己足以服人，量宽足以得人，身先足以率人。
【译文】轻视财物可以召集人，律己可以让人敬服，气量宽广可以得人心，自己亲身先做事可以领导人。
●惟正己可以化人，惟尽己可以服人。
【译文】只有端正自己可以感化别人，只有开放自己的心才可以服人。
●遇诡诈人变幻百端，不可测度，吾一以至诚待之，彼术自穷。
【译文】遇到诡秘狡诈的人变化百端，不可以猜测度量，我都用至诚心对待他，他的方法就没用了。
●功不独居，过不推诿。
【译文】有功劳不自己一个人占有，有过错不推脱。
●不可轻率评讥古人。
【译文】不可以轻易评论讥讽古人。
●今日所说之话，明日勿因小利害而变。
【译文】今天讲的话，明天不要因为小的利害就改变。
●遇棘手之际，须从耐烦二字痛下功夫。
【译文】遇到棘手的时候，要从耐烦这两个字上下功夫。
●勿以小恶弃人大美，勿以小怨忘人大恩。
【译文】不要因为别人小的坏处而放弃他大的优点，不要因为与别人小的仇怨而忘记他的恩情。
-----------------曾国藩箴言（二）--------------------
●责过太直，使人惭恨，在我便是一过。
【译文】指责过错过于直接，让别人生惭愧而痛恨自己，对我来说就是一种过错。
●受挫受辱之时，务须咬牙励志，蓄其气而长其智。
【译文】受到挫败和侮辱时，一定要咬紧牙忍受来激励志向，继续志气，增长智慧。
●行事不可任心，说话不可任口。
【译文】做事不可以随心所欲，说话不可以随口胡说。
●百种弊病，皆从懒生。
【译文】很多的弊病都是从懒惰生出的。
●守笃实，戒机巧，守强毅，戒刚愎。
【译文】谨守笃定老实，不要投机取巧，尽收刚强坚毅，不要刚愎自用。
●凡人做一事，便须全副精神注在此一事，不可见异思迁。
【译文】凡是有人要做一件事，就须把全副精神贯注在这件事上，不可以见异思迁。
---------------曾国藩箴言（三）---------------
●寡言养气，寡视养神，寡欲养精。
【译文】少说话可以休养元气，少看可以休养心神，减少欲望可以休养精气。
●礼义廉耻，可以律己，不可以绳人。
【译文】礼义廉耻，可以用来要求自己，却不能用来要求别人。
●利可共而不可独，谋可寡而不可众。独利则败，众谋则泄。
【译文】利益可以共享不可以独享，谋划可以让少数人知道不可以让多数人知道，独享利益就会失败，谋划让多数人知道就会泄露。
●久利之事勿为，众争之地勿往。物极则反，害将及矣。
【译文】能一直产生利益的事不要做，众人争夺的好地方不要去。物极必反，祸害就要来了。
●知足则乐，务贪必忧。
【译文】知足就会快乐，执着贪心就会忧虑。
●处事宜决断。
【译文】处理事情应该坚决果断。
●事到手且莫急，便要缓缓想。想得时切莫缓，便要急急行。
【译文】事情分配到手上先别急，要慢慢想。想到时不要拖延，要赶快做。
●尖酸语称快一时，当之者终身怨恨。
【译文】尖酸刻薄的话让你一时痛快，可对方却终身怨恨你。
●凡权要人声势赫然时，我不可犯其锋，亦不可与之狎，敬而远之，全身全名之道也。
【译文】凡是掌握权力的重要人物声名、势力非常大的时候，我们不要去触犯他的锋芒，也不可以和他交好。对他敬而远之，是保全自己名声、生命的方法。
●行事常思退一步。
【译文】做事常常要想到退让一步。
●慎言谨行，是修己第一事。
【译文】谨慎自己的言行，是修养自己德行的最重要的事。
logstash日志处理采用队列ZMQ，压力会很好的被缓冲，针对高并发的大数据量的日志处理是没有问题的，日志利用ES存放，就是个基于lucene的全文检索数据库，也不存在数据量的问题。
logstash 是一个应用程序日志、事件的传输、处理、管理和搜索的平台。
你可以用它来统一对应用程序日志进行收集管理，提供 Web 接口用于查询和统计。
