职位搜索_为什么我的智联招聘职位搜索不了。其他的智联招聘网站都行的，就职位搜索的时候不行，找不到服务器。

大家好！今天让小编来大家介绍下关于职位搜索_为什么我的智联招聘职位搜索不了。其他的智联招聘网站都行的，就职位搜索的时候不行，找不到服务器。的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。

文章目录列表:

前程无忧51job的应用介绍

1、职位搜索：支持多种搜索条件，并可针对搜索结果进行筛选。

2、My51job：完善的在线求职管理中心，随时进行简历刷新、修改、预览，查看职位申请、收藏记录等。

3、企业粉丝团：随时随地与企业及粉丝交流，了解企业动态，与千万粉丝聊聊职场那点事。

4、实时消息推送：想知道谁看过我的简历？前程无忧第一时间告诉你，保证你先人一步。

5、职场资讯：为求职者提供就业指导、面试技巧等，为职场人生提供帮助。

6、薪酬查询：专业的个人薪酬参考，你的'薪'事我知道。

7、校园招聘：超200万的全职、实习、兼职岗位，校园宣讲会信息，名企校园招聘进度。

为什么我的智联招聘职位搜索不了。其他的智联招聘网站都行的，就职位搜索的时候不行，找不到服务器。

1、前程无忧是成立于中国的一家互联网企业其APP有职位发现以及职位搜索功能，支持一键刷新简历，对于在线简历拥有谁看过我的功能，同时支持薪酬查询功能，还有校园招聘会可以在线寻找心仪的工作。

2、智联招聘是一个拥有众多招聘选择的求职APP，拥有职位推荐功能，可以在线搜索附近职位，同时可以屏蔽相关企业，支持HR约聊，双方可以在线进行沟通。

3、58同城这个网站也是比较靠谱的，不过上面招聘的信息比较少，但比较真实，这个上面招聘的岗位比较广，适合于广大群众，中高级别的岗位相对来说较少一些。

4、赶集网APP是一款信息量覆盖面较为广泛的信息平台，拥有较多的工作岗位可以进行选择，主要有以下特色功能:老板直聘、工作地域选择、优选工作以及猜你喜欢四个工作特色功能。

5、Boss直聘与其他招聘软件类似，可以除了在线搜索相关的企业之外，其主要功能是支持在线交流，可以在线交流工作相关岗位的信息。

Redis 实战 —— 10. 实现内容搜索、定向广告和职位搜索

原因可能是智联招聘的搜索数据库后台更新，导致你短时间不能访问。

建议你搜索的时候，最好详细填写搜索信息，缩短数据库查询读取的时间。

如：

1、职位类别

2、职位名称

3、行业类别

4、发布时间

5、工作地点

6、关键词

通过改变程序搜索数据的方式，并使用 Redis 来减少绝大部分基于单词或者关键字进行的内容搜索操作的执行时间。 P154

倒排索引 (inverted indexes) 是互联网上绝大部分搜索引擎使用的底层结构，它类似于书本末尾的索引。倒排索引从每个被索引的文档里面提取一些单词，并记录包含每个单词的文档集合。 P154

示例

假设有三个文档：

我们就能得到下面的倒排索引集合：

检索的条件 "what", "is" 和 "it" 将对应这个集合： {0,1} ∩ {0,1,2} ∩ {0,1,2} = {0,1}

可以发现 Redis 的集合和有序集合非常适合处理倒排索引。

基本索引操作

从文档里面提取单词的过程通常被成为语法分析 (parsing) 和标记化 (tokenization) ，这个过程可以产生一系列用于表示文档的标记 (token) ，有时又被成为单词 (word) 。 P155

标记化的一个常见的附加步骤就是移除非用词 (stop word) 。非用词就是那些在文档中频繁出现却没有提供相应信息量的单词，对这些单词进行搜索将返回大量无用的结果。 P155

本书中实现方向索引的逻辑非常简单：

如果需要支持中文等，就不能简单进行英文分词，需要分词器进行处理。第一次接触倒排索引是在 Elasticsearch 中，感兴趣的可以了解 Elasticsearch 中倒排索引的实现以及 IK 中文分词器。

基本搜索操作

在索引里面查找一个单词是非常容易的，只需要获取单词集合里面的所有文档即可。根据多个单词查找文档时，就需要根据条件处理对应的集合，再从最终集合中获取所有文档。 P156

可以使用 Redis 的集合操作完成对不同条件的处理：

通过以上三类命令，我们基本能实现条件大部分的与或非操作。

分析并执行搜索

我们使用的查询语句进行分词后具有以下特征：

即： "connect +connection chat -proxy -proxies" 表示查询的文档需要包含 "connect" 或 "connection" ，同时也要包含 "chat" ，并且不能包含 "proxy" 和 "proxies" 。

实际处理时，先对同义词组分别取并集，然后与需要查询的单词一起取交集，最后与不希望包含的单词取差集，这样所得到的集合就是用户查询的结果集。

上述搜索功能以及能够搜索出用户查询的所有文档唯一标识的集合，现在我们将根据这个文档唯一标识集合以及每个文档的具体信息进行排序分页。

对于这种情况我们可以使用 Redis 的 SORT 命令对文档唯一标识集合通过引用每个文档的具体信息进行排序分页。 （ 05. Redis 其他命令简介 ）

上面介绍了使用 Redis 进行搜索，并通过引用存储在 HASH 里面的数据对搜索结果进行排序分页。接下来将介绍利用集合和有序集合实现基于多个分值的复合排序操作，它能提供比 SORT 命令更高的灵活性。 P162

假设我们目前需要根据文档对更新时间和得票数进行排序，为此我们需要用两个有序集合存储相关信息。这两个有序集合的成员都是文档唯一标识，成员的分值则分别是文档的更新时间和得票数。

设经过搜索后满足搜索条件的文档唯一标识集合为 filtered_doc_ids ，文档唯一标识及其更新时间对应的有序集合为 doc_ids_with_update ，文档唯一 标识及其得票数对应的有序集合为 doc_ids_with_votes 。那么可以通过 ZINTERSTORE 命令对这三个集合求交集，最后得出的满足搜索条件的文档唯一标识及其排序分值对应的有序集合，再使用 ZRANGE , ZREVRANGE 进行分页获取即可。 P162

示例： ZINTERSTORE filtered_doc_ids_with_sort_score 3 filtered_doc_ids doc_ids_with_update doc_ids_with_votes WEIGHTS 0 {update_weight} {vote_weight}

其中：

所思

这种利用分值的方法很巧妙，基本可以实现多字段排序，但是优先级可能难以掌控，难以做到先按照某一字段排序，再按照另一字段排序的形式。因为每个字段对应的分值的数量级可能差别比较小，这个时候如果需要有排序字段的优先级，那么可能需要对每个权重进行精巧地设计才行。

上面介绍了使用有序集合对多个数值字段进行排序，由于有序集合的分值只能是浮点数，所以非数值字段不能直接用于排序，需要转换成对应的浮点数。但由于双精度浮点数只有 64 个二进制位，实际能使用 63 个二进制位，所以能表示的字符串并不多，只能使用字符串的前几个字符进行分值估计，不足指定字符数的需要补齐到指定字符数。当然如果字符集缩小的话，可以重新进行编码计算，进而可以对更长的字符串进行分值估计。 P165

当这个分值特别大的时候，可能会引发最终计算的分值溢出而出错的问题。

接下来将介绍使用集合和有序集合构建出一个几乎完整的广告服务平台 (ad-serving platform) 。 P166

针对广告的索引操作和针对其他内容的索引操作并没有太大的不同，被索引的的广告通常都拥有像位置、年龄和性别这类必需的定向参数，并且往往只会返回单个广告。 P167

广告的价格 P167

为了尽可能简化广告价格的计算方式，将对所有类型的广告进行转换，使得它们的价格可以基于每千次展示进行计算，产生出一个估算 CPM (estimated CPM, eCPM) 。 P168

将广告插入倒排索引 P169

我们基本可以复用上面提到的搜索功能，除了会将广告的关键词插入倒排索引，还会将广告的定向参数（位置、年龄和性别等）插入倒排索引中，并记录广告的类型、基本价格和 eCPM 价格。 P169

当系统收到广告定向请求的时候，它要做的就是在匹配用户定向参数的一系列广告里面，找出 eCPM 最高的那一个广告。同时，程序还会记录页面内容与广告内容的匹配程度，以及不同匹配程度对广告点击通过率的影响等统计数据。通过使用这些统计数据，广告中与页面相匹配的那些内容就会作为附加值被计入 CPC 和 CPA 的 eCPM 价格，使得那些包含了匹配内容的广告能够更多地被展示出来。 P170

计算附加值

计算附加值就是基于页面内容和广告内容两者之间匹配的单词，计算出应该给广告的 eCPM 价格加上多少增量。每个单词都有一个有序集合，成员为广告 id ，成员的分值为当前单词对这则广告的 eCPM 的附加值。 P171

在寻找合适的广告时，我们首先会过滤出匹配定位位置且至少包含一个页面单词的广告，然后通过计算附加值的方法替代搜索，以便实现每次投放价值最高的广告，并能够根据用户的行为学习。同时由于每个广告匹配的内容不同，最优方式应该是使用加权平均值来计算单词部分的附加值，但限于 Redis 本身的命令，我们最终采取 (max + min) / 2 的形式计算单词部分的附加值（max 表示所有匹配单词的最大附加值， min 表示所有匹配单词的最小附加值），采用如下命令即可： ZUNIONSTORE final_score 3 base max min WEIGHTS 1 0.5 0.5 。

从用户行为中学习 P175

首先需要存储用户的浏览记录，包括三部分：（每 100 次就主动更新一次 eCPM ） P175

其次需要存储用户的点击和动作记录，用于计算 点击通过率 = 点击量或动作次数 / 广告展示次数。（每次都更新 eCPM） P176

最后就是更新 eCPM ，包括两部分：

接下来将使用集合和有序集合实现职位搜索功能，并根据求职者拥有技能来为他们寻找合适的职位。 P180

第一反应肯定是直接对每一个求职者搜索所有的岗位，从而找到求职者合适的岗位。但这种方法效率极低（大部分岗位肯定是技能对不上的），而且无法进行性能扩展。 P181

使用类似上面提到的附加值形式，每次添加一个岗位时，在对应的技能集合中添加这个岗位的 id ( SADD idx:skill:{skill} {job_id} )，再在岗位有序集合中进行添加，成员为岗位 id ，成员的分值为所需的技能数量 ( ZADD job_required_skill_count {job_id} {required_skill_count} )。搜索的时候就先对求职者所有技能对应的集合使用 ZUNIONSTORE 操作计算每个公司匹配的技能数量 ( ZUNIONSTORE matched {n} idx:skill:{skill} ... WEIGHTS 1 ... )，然后再与岗位有序集合求交集，并让公司有序集合的权重为 -1 ( ZINTERSTORE result 2 job_required_skill_count matched WEIGHTS -1 1 )，最后获取分值为 0 的所有岗位即可完成搜索。 P181

所思

书上的这个方法比较麻烦，其实可以使用文章最开始的无序倒排索引，岗位相当于要搜索的文档，岗位所需的技能相当于单词。