Monthly Archives: September 2006

+ 不做太多的分类搜索，比如分开商品、折扣、商店这样的分类来让用户选择性搜索，这样的选择让人迷惑，”选择”可以作为高级功能来提供给用户。不能把“商品”和“折扣”作为分类分开，因为这样选择太多，太麻烦。要求智能，自动计算和猜测用户想搜索什么，想得到的是什么样的搜索结果。建议搜索框只有一个，根据用户在搜索框中输入的内容，猜测用户最想得到的是什么样的结果，根据这个猜想来进行搜索。比如用户输入“手机 折扣”或者“手机 打折”，那么就说明这个用户想搜索的是关于手机打折方面的信息，我们的后台程序对“折扣”这样的典型或者高频的词应该进行优化，目的是让用户搜索到的是折扣类的信息，而不是仅仅包含“折扣”这个词的信息。又例如用户输入“ipod 重庆”，这样用户想搜索的是什么呢？用户想搜的是在重庆卖ipod的商店，而不是仅仅包含“手机”和“重庆”两个关键词的信息。 举一个我前段时间想找买颗小螺丝和小螺丝刀的例子作为过度。前几天我有个数码产品上面的小螺丝掉地上，不知道滚到哪里去了，找不着，怎么办？没有那颗螺丝可不行，盖子盖不好，我想去买一颗。去哪里买？我不知道:( 然后我在家里找有没有其他的东西上有这么小的螺丝，最后在一个废充电器上面发现有，但是螺丝很小，那个孔也很小，我想要个小起子，把那颗螺丝起起来。我也不知道在北京这里哪里能买到小的起子，去电脑城问？太麻烦了，要是在网上能查到我附近哪些商铺有的卖就好了。最后我把充电器砸了才拿到那颗小螺丝，才发现那颗螺丝小了一点，不合适。 + 不仅仅能对网上商店的搜索。用户进行购物搜索的目的，我自己估计（当然不能代表全部，只是说明我有这样的想法，我也曾问三个朋友，一个技术人员、一个摄影师、一个是家庭主妇），很多时候不是为了在网上的商店上买东西，而是，一、看看关于某种商品的介绍和网友的评论，能找到商品的价格范围，不用担心被骗；二，希望找到自己周围有哪些商店出售这种商品，方便自己去购买，最好能在地图上显示。我相信大部分用户存在这样的需求。 + 关于一些周边的附加功能，如“相关产品、用户可以在地图上添加某种商品可以在哪些地方买到、积分问题”等。目前我不想考虑，等第二期或者第三期的开发。我觉得目前考虑的重点是商品搜索，尽最大的努力让用户得到他最想得到的结果，这样这个服务才能让更多的用户使用。让用户想买东西的时候，必先用我们的服务，才是第一期的目标。 + 不推荐这个项目太过着重于价格的比较，因为我觉得单纯的竞价搜索会破坏良性的商业环境。商家的利益受到损害，就不能给用户提供更好的服务。我担心破坏我们和这些网上商城的关系，不方便于以后的合作。或者我们可以利用这点，和网上商城沟通，尽量达成一致来打击其他的竞价搜索引擎。所以这个项目的重点是“导购”，是帮助用户轻松买到他想要的商品。价格的比较只能作为其中的一项服务，并且只适合于网上商城。这个需要进一步权衡利益。 为了满足上面用户的需求，我们的系统应该怎么做？要求聪明、表达清晰、功能强大(绝大部分功能并非面向用户，而是面向我们的聪明程序，聪明的程序主要是负责在猜测用户在想什么，需要得到怎样的结果)

阅读相关的资料后，对前段时间购物搜索项目的想法。 重点： 通过对商品所在商家等级，商品价格，商品评价等的综合考虑来确定某一款性价比最高的商品做为购买对象。 ——————– 如果综合考虑？商家等级如何定？商品价格怎样才算合适？商品评价(某个还是某种)？ 网店的注册用户数，交易量，交易的成功率，交易的地域范围。 其次： 打折\活动信息如何取得，如何优化？

英文原版，由钟子昌翻译整理 最新版的 Tomcat servlet 容器提供集群和负载均衡的能力，对于部署可升级、健壮的Web应用来说，这是必不可少的。这篇文章的第一部分描述集群与负载均衡的特性和要点。第二部分举出一个如何配置 Tomcat 集群的实例，同时介绍在集群环境中使用内存复制的方式来实现 session 的持久化 。 Tomcat 5 自带一个基于规则的负载均衡应用。根据两种负载均衡策略（扩展自规则API，分别是 round-robin 和 random 算法）来重定向进入的请求。讲述运行在集群环境中的样例Web应用的性能评测。通过负载测试工具 JMeter 模拟多个Web用户的方式来研究负载均衡机制。 + 大型系统的设计 企业级的 Web 门户应用必须提供可升级能力（scalability）和高可用性（HA），在同一个网站下为数以百万计的用户提供服务。可升级是系统可以通过增加服务器来支持更多的数量的用户。高可靠性是系统提供基本的冗余能力。在集群中的某个成员失效时，其他成员能透明的接替处理对 Web 服务的请求。在集群的环境中部署一个 Web 门户应用能提供门户网站需要的可升级和高可用性的能力。基本上，集群的主要目的是防止某些站点出现当机的问题，应付系统的单点失效。 大型系统的设计目的是在企业应用环境中提供稳定的服务，确保最少的当机时间和最大的可升级能力。运行的不是单一的服务器，有多个协作服务器也同时在运行。为了达到可升级的能力，集群能任意增加机器数量，而为了最少的当机时间，集群中每一个组件都是可冗余的。大型系统的主要因素就是集群，包含负载均衡、容错、session 状态持久化等特性。在集群中，通常负载均衡器（硬件或软件）布置在应用服务器的前面。这些负载均衡器通过使用重定向 Web 交易到相应的集群成员来在集群的节点内分发负载，并且在同时检查集群内是否有服务器失效。 + 集群 集群的定义好比一组应用服务器透明的运行J2EE应用，就象在一台机器上执行一样。有两种方式的集群：垂直缩放和水平缩放。垂直缩放可以通过提高单台机器上的运行服务的数量来达到，水平缩放就要提高集群内机器的数量。水平缩放比垂直缩放更可靠。使用垂直缩放，机器的处理能力、CPU的使用情况和JVM堆内存配置都是决定应该在这台机器上运行多少的服务器实例的主要因素（众所周知的 server-to-cpu 比率）。 J2EE集群内的服务器一般使用三种配置选项的一种： 独立（independent），每个服务都有属于自己的一份应用程序文件的拷贝； 共享文件系统（shared … Continue reading →

忽然之间觉得经常去的那几个网站的信息满足不了我的阅读需求。想发掘和阅读一些来自blog的内容，却又不想化那么多时间去收集新的信息源。 我需要系统做到如下几点： 1. 自动收集信息源，自动将信息源分等级，将低等的信息源定期排出，维持信息源的数量在一定数量（如1w）之内； 2. 提供搜索功能，让我可以在这1w个精品信息源内找我想要的信息； 3. 自动将我最感兴趣的内容聚合到一个页面上，在我没什么时间的时候，浏览一下这个页面就可以了； 4. 信息更新的频度，当然是越快越好:) 在考虑是否把 blog search engine 重新安装上，专门做这方面的事。