• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

  cctv podcast虽然起步较早，不过现在无论在流媒体技术，展现，以及概念上都已经显得比较落后。央视podcast的主要内容来自编辑部门的电视节目，以及部分网友上传的电影和歌曲，原创作品不多；其他网站也大同小异，鉴于podcast制作比写blog复杂很多，大面积复制传播形成主流方式，像博客一样所有都自己动手弄自己的是一种不可能达到的状态。

  所以，从某种意义上说，podcast并不是一种以个人为中心的类型，和blog没有可比性。podcast的发展概念应该超越blog，在blog和 wiki之间。blog的理念是自己为中心，自己写自己的文章，展示自己的文章，图片等等。wiki的理念在于共创，通过集体的力量完成某一件事情，而这个事情完成以后并不归属于自己，所以可以推断wiki是一种更加高层次网民素质的体现，因为wiki体现的是一种奉献精神，而高于blog的个人中心精神。

  podcast，由于内容主要来源与复制传播，而并非原创；所以按照发布者进行组织是一种不妥当的选择，比较合适的组织方式应该是按照创作者。按照视频原始创作者进行组织，发布者通过贡献自己手中的视频来完成对某一主题，某一人视频的汇集，从而为普通的视频观看着提供某一方面更多更加准确全面的视频资料，提供观看者的体验程度。所以podcast的视频组织方式在理想状态下，应该按照wikipedia的方式进行处理；不过和wiki不同，podcast 发布者自身也可以创建视频，所以wiki标准的固定词条在此处不适用，podcast同时拥有者wiki概念上需要大家一起贡献来汇总的公共视频，也有个人自己录制的原创内容，个人的概念不可以被忽略。

    按照上面的分析，如果对互联网划带，应该是：web1.0 -> 以blog为代表的个人中心内容 web2.0 --> podcast应该体现出的个人与贡献内容的混合 web2.5 -> 以社会为中心，个人齐心贡献的内容模式，如wiki web3.0.    

    明确了概念，podcast隶属于web2.5系统，所以相对于目前主流的个人为中心表现形式，它应该更多表现出其应有的共有奉献型资源的特性。podcast的组织结构应该满足：

1. 按照作品的原创者进行组织。（按导演）
2. 按照作品的演出者进行组织。（按表演者）
3. 按照发布者进行组织。（按照作品上传发布者）
4. 按照视频归属事件进行组织。（按反应的事件）

  视频贡献者：根据某些调查，互联网内容的贡献者一般年龄层次较高，心态较高。而对于视频，由于其特殊性，一般贡献者比较熟悉计算机，网络等新鲜技术，心理年龄一般应在25---40之间，其中对于奉献型组织的支持者一般应该在30以上。对于发布者发布的流程，应该更加体现简洁性与流程性，提高对这一特定群体的满意程度。

  视频消费者：视频消费者应该可以当作一帮懒惰的人来考虑，他们期待着更少的操作，更少的页面转换，更大的视频窗口，更高的质量以及更好的视频流畅程度；对于他们来说可以理解为希望打开网站以后自己想要的东西都有了，一个个的为他们播放，他们自己则几乎什么都不需要做。为了满足他们的需要，在内容组织方式上提出了更高的要求，这个我们在上面已经提出了，同时视频还要有较强的推荐功能，通过分析当前用户的历史习惯或者他们选择的偏好，进行相关视频的推荐。而播放器也需要有更多的操作选项，提供更好的体验。

   播放器需求：

1. 可以支持IE6, IE7和firefox
2. 拥有普通的屏幕功能和全屏功能
3. 媒体播放开始，暂停，停止功能，音量调节功能等。
4. 播放列表功能
5. 可以在媒体播放的片头，片尾，甚至片中任意位置插入其他视频。（放广告，紧急通知新闻啥的）
6. 提供两个文本层，一个固定文本层，一个活动文本层，播放器可以与服务器交互，让服务器控制着文本层文字内容的播放。（留作放广告，字幕，介绍，媒体的最新评论，最热门评论什么的）
7. 播放器可以方便的增加链接，如为当前播放媒体的评分功能，显示当前媒体评分等。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

MySQL Select and Sort Status Variables

1. Select_scan
2. Select_range
3. Select_full_join
4. Select_range_check
5. Select_full_range_join
6. Sort_scan
7. Sort_range
8. Sort_merge_passes
9. Sort_rows

The Distinction Between Where the Variables Apply

   mysql> EXPLAIN SELECT * FROM tbl2, tbl1 WHERE tbl1.col1 = tbl2.col2 ORDER BY tbl1.col2;
   +-------------+-------+------+---------------+------+---------+------+------+------------------------+
   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                  |
   +-------------+-------+------+---------------+------+---------+------+------+------------------------+
   | SIMPLE      | tbl2  | ALL  | NULL          | NULL | NULL    | NULL |   18 | ..temporary;.. filesort|
   | SIMPLE      | tbl1  | ALL  | NULL          | NULL | NULL    | NULL |   27 | Using where            |
   +-------------+-------+------+---------------+------+---------+------+------+------------------------|
   

1. First table or only table: Select_scan and Select_range
2. Second and subsequent tables: Select_full_join, Select_range_check, and Select_full_range_join
3. Any query that uses ORDER BY or GROUP BY: Sort_scan, Sort_range, Sort_merge_passes, and Sort_rows

Select_scan

Select_range

Select_full_join

Select_range_check

   mysql> EXPLAIN SELECT * FROM tbl1, tbl2 WHERE tbl1.col1 > tbl2.col1;
   +-------------+-------+------+---------------+------+---------+------+------+----------------------+
   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | Extra                |
   +-------------+-------+------+---------------+------+---------+------+------+----------------------+
   | SIMPLE      | tbl1  | ALL  | NULL          | NULL | NULL    | NULL |   27 |                      |
   | SIMPLE      | tbl2  | ALL  | col1          | NULL | NULL    | NULL |   18 | Range checked for..  |
   +-------------+-------+------+---------------+------+---------+------+------+----------------------+
   Range checked for each record (index map: 0x1)

Select_full_range_join

   mysql> EXPLAIN SELECT * FROM tbl1, tbl2 WHERE tbl1.col1 = 10 AND tbl2.col1 > 13;
   +-------------+-------+-------+---------------+------+---------+-------+------+-------------+
   | select_type | table | type  | possible_keys | key  | key_len | ref   | rows | Extra       |
   +-------------+-------+-------+---------------+------+---------+-------+------+-------------+
   | SIMPLE      | tbl1  | ref   | col1          | col1 | 5       | const |    1 | Using where |
   | SIMPLE      | tbl2  | range | col1          | col1 | 5       | NULL  |    1 | Using where |
   +-------------+-------+-------+---------------+------+---------+-------+------+-------------+

   

Sort_scan and Sort_range

1. Find rows based on WHERE conditions
2. Sort rows
3. Read rows in sorted order

Sort_merge_passes

Sort_rows

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

1. hibernate自带缓存的情况介绍

hibernate提供了两种缓存，一个是基于对象主ID的一级缓存和一个为缓存查询结果而设计的二级缓存（姑且叫作查询缓存），一级缓存是默认开启的， 而且似乎也是很难关闭的；查询缓存默认是关闭的，而在我的印象中则一直觉得这个东西是“没有价值的”，至今没有看到典型的使用案例和使用模式。

hibernate提供的查询缓存，默认会去cache所有的查询请求，而这对于常用的系统而言是完全没有必要的。大多数真正需要缓存的应用场景，往往是 数据量庞大，交互操作较多的系统，而一般真正需要缓存的数据只有少量的查询，如果所有的查询都缓存，缓存的效率会大大降低而且会浪费很多内存，可能效率还 不如不用缓存。例如javaeye论坛的版面帖子列表，我们希望缓存的往往也就是每一个版的第1，2页帖子，如果用户翻老帖子，则不去缓存。这种场景应该 是经常用到的缓存场景，而hibernate查询缓存恰恰不能自动做到，这个就是我们将要讨论解决的问题。

2. 我们会用多少的查询缓存？

一级缓存HibernateTemplate只有load()和get()方法才会使用，如果您用的是list(..;)或者其他的方法都是不缓存的。如果您的系统有内容审核这么一说（如只有审核通过的才能对外显示，删除的不对外显示等等），即使是提取一个帖子（可以用get()的情形），你们组程序员提取数据的语句一般也会写成list(from XXXX where id = … and 状态 = 审核通过的)，以图方便或者为了数据库连接可以为readonly事务，这样hibernate仅有的一级缓存也会被跳过，您的查询语句都是没有缓存的！这时候一个有效的查询缓存将会给你的系统带来巨大的性能提升。

3. 一般的应用场景与通用的查询缓存应该具备的功能

缓存的使用目的是为了提供性能，缓存的使用后果是数据将会有延迟。如果我们决心使用缓存，一般的应用场景应该具有如下特点：事务要求低，数据实时性要求低，并发量要求高，系统可扩展性要求高，机器硬件成本要求低，总之非常适合大面积的空间换时间设计方法并且对数据的完整/准确度要求不高。

缓存还应该是通用的，应用系统只要配置下即可使用；不能每个系统都单独开发，这样也就没有讨论的意义了。

对于要缓存的东西，往往应用本身而且只有应用本身了解什么情况下需要缓存，所以查询缓存应该提供接口，由应用提供解释，来描述哪些查询是需要缓存的，哪些是不需要缓存的。如对于论坛的版面帖子列表，应用可以告诉缓存模块：Java版缓存第1，2页的帖子，回收站不做缓存，其他版面缓存第1页帖子列表，如果用户是登录用户则所有版面的帖子列表都不做缓存；只有这样才能真正的提高缓存的效率，降低缓存成本。

4. 一种基于域对象的缓存实现方式

针对前面的描述，偶做了一个实现，基于annotation的定义（当然可以基于xml配置或者基于数据库，然后可以在线的调试配置参数达到最优）。定义如下：

各项定义解释：

• Cachable ，指定这个实体是要进行缓存的。interval=5，表示对象cache 5秒失效。
• QueryCondition为一般的查询缓存，指定那些条件下进行结果集cache，如此处就是说当条件为cateogory=某一个值，并且按照id desc进行排序时cache查询记录的前30条（如果一页显示15条，则缓存第1，2页，第3，4，5。。。不做缓存）。或者当条件为parentCategoryId=?并且status=10进行缓存，缓存不考虑排序字段，并且缓存所有结果。
• UnqiueConditon，指定对象的唯一性条件，当满足这个条件时可以保证数据库只有一个对象，常见情形如用户表的username, nickName，id等。此处按照id查询时进行缓存，最多缓存2000条记录；如果按照word字段进行查询，也进行缓存，最多缓存2000条记录。如对于查询条件 id = 134343 and status = 10 ;cache分析出含有记录唯一保证的字段id，status就可以暂时忽略，先通过id=134343从cache中读取记录，然后在利用好比反射的方 法查看对象的status是否为10，如果是，就直接对象，不是返回null；保证同一个对象尽量占用同样的cache位置。
• CacheIngoreUpdateField 这个表示忽略的更新字段。因为clickCount用户每次打开都会更新+1，如果此时刷新cache，cache也就可以撤消了。所以我们通过定义 这个标记，如果某一个update操作只是更新了clickCount字段，只更新数据库，cache依然有效不做更新。等到Cachable标记的 interval让对象失效以后再更新，保证cache的低刷新频率。
• QueryConditionIgnoreParseField 表示此字段不参与是否需要cache的匹配，如此处的symbolLength，只要标记了@ QueryConditionIgnoreParseField，无论查询条件中有没有symbolLength条件，都不影响查询缓存决定当前查询是否需要做缓存。
• Entity为hibernate的标记。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师