3

我在一家软件商店工作,该商店有一个内部预测拨号器产品,我们需要实施一个解决方案来遵守 DO-NOT-CALL 列表。

基本上,我有一个包含我需要拨打的客户/潜在客户的数据库,以及另一个包含我无法拨打的电话号码的数据库。由于该系统是一个预测拨号器,根据操作性能、时间平均值等,它会为每个登录的系统用户拨打或多或少的电话。通常这个“神奇”数字是每个登录的代理大约 3 到 4 个呼叫。

预测拨号器的电话号码存储库是一个 PostgreSQL 数据库。预测拨号器从数据库中挑选一堆号码,然后向 pbx 发送一个命令来拨号,然后业务逻辑继续将有效呼叫转移到呼叫中心文员等(这与我的无关问题是在通话之前)。

我需要实现请勿呼叫列表功能。政府机构将每天以 CSV 文件的形式向我们公司提供此拒绝来电清单。每次我收到一个新的 CSV 文件时,我都必须清除旧的请勿呼叫列表,并将新的放在适当的位置。

我实现它的第一个想法是进行批处理,将 DO NOT CALL LIST 与我当前的客户数据库进行交叉引用。但我认为,根据两个数据库的大小,交叉引用会非常耗费性能,有时无法在一夜之间完成。我以前在批处理时遇到过这种问题,这不是一件好事。

当我想到大型机构如何处理高性能和高吞吐量的授权系统(例如信用卡或用户身份验证/授权)时,我的第二个想法出现了。我认为为 DO NOT CALL LIST 号码创建身份验证服务,并更改我的预测拨号器的算法以在拨号之前根据此授权服务检查每个号码会很整洁。

由于我只是在这里胡说八道,我不知道哪个想法是最好的,或者我是否完全错了,应该转向另一个方向。所以,我的问题是:你的建议是什么?将 DO NOT CALL CSV 文件存储在内存中?使用 LDAP?使用 MySQL?PostgreSQL?做批处理的事情吗?还是我绝对搞砸了?

我知道我不是世界上第一个遇到这种问题的人,所以请赐教。

4

1 回答 1

2

您的挑战是从大量可能的条目中查找多个条目,这让我想起了DNS 黑/黑名单

rbldnsd是一个小而快的 DNS 守护程序,专门用于服务 DNSBL 区域。这个守护进程的灵感来自于 djbdns 包中的 Dan J. Bernstein 的 rbldns 程序。更多 rbldnsd,来自 Google

它支持基于名称的区域,因此您可以将数字列表转换为 ENUM 样式的 URI - 例如 +1-555-4242 变为 2.4.2.4.5.5.5.1.e164.arpa。然后将其输入 rbldnsd 数据文件,编译到内存中并像任何其他阻止列表一样访问。默认条目意味着可以调用,或者如果该条目存在,则将给予它一个 DoNotCall 条目。

不过,您仍然遇到批量转换问题,尽管它会是一个稍微简单的脚本,很可能与 Perl 或 AWK 一起使用。您还可以将传入的 CSV 文件拆分为多个文件以进行并行处理和最终合并。

于 2009-04-17T20:17:20.987 回答