有很多个图书馆，每个图书馆有自己的图书和读者，之前是每个图书馆的读者只能借自己馆的图书。现在要做成各个馆的图书可以互相借阅，并且可以在任意一个馆归还图书。
架构这样设计：
每个图书馆都有相同的借书系统，各个系统只存储本馆的图书、读者，然后再撘一个*服务器，然后把所有图书馆的图书和读者放一份放到中心服务器，并且*服务器也有借书、还书逻辑。
业务说明：读者借书，会生成一条借阅事务，同时图书的状态也会改变为“外借”状态。
具体的借书过程：读者借书时，先发送借书请求到中心服务器，中心服务器先做借书操作，如果中心服务器成功，本地写借书事务和改变图书状态；如果不是本馆图书，中心服务器会有同步操作，把图书状态更新的操作同步到图书所属的图书馆。
大家觉得这种架构有没有什么问题，有没有更好的设计？
27 个解决方案
#1
如果整体系统都是自己做的话，一种是做成一套系统。
还有一种是做成多套，每本书都有个归属图书馆的概念，书号中用2-3位表示归属图书馆。
对书而言，增加一个所在地，还有一个叫馆借的状态。
*服务器的话，其实有点复杂，万一当机，影响也比较大，能不用就不用。
还有一种是做成多套，每本书都有个归属图书馆的概念，书号中用2-3位表示归属图书馆。
对书而言，增加一个所在地，还有一个叫馆借的状态。
*服务器的话，其实有点复杂，万一当机，影响也比较大，能不用就不用。
#2
*服务器宕机的话，是考虑本地写离线记录，等*服务器恢复后，上传上去。
#3
1。现在应该是每个图书馆都有自己的系统，不会都换，那么就需要调用已经存在系统的接口
2。调用原有系统最小修改的方法还是在最大的图书馆架设互相借阅的服务器
3。对于借阅的问题
现在要做成各个馆的图书可以互相借阅，并且可以在任意一个馆归还图书。
这个我理解应该是，我在 A 图书馆办理借书证，要借 B 图书馆的书，那么应该不是这种，提交请求，B图书馆送书过来，
最简单应该是我在 A 图书馆查询是否有这本书，然后得知在 B，于是去 B 借阅。
那么服务器需要做的是，查询功能，以及存储，你说借阅的书可以在 C 图书馆换，那么互相借阅的记录要解决两个问题
第一 B 图书馆保存 A 图书馆用户借阅该书信息
第二 服务器保存 B 借阅信息 ID 以及，A 图书馆用户 ID
保存之后在 C 图书馆可以在服务器查询到 A 图书馆用户信息，与 B 图书馆书籍信息，提供还书服务，通知 B 图书馆修改书籍态，服务器保存该图书在 C 图书馆，归还后删除，以及通知 A 图书馆用户已经把书归还，借阅书籍数量减少
那么需要已经有的图书馆系统提供书籍借阅接口，用户接口，书籍查询接口
还需要可以保存其他图书馆用户借阅本图书馆书籍信息
对于*服务器可以设双服务器，并行存储
2。调用原有系统最小修改的方法还是在最大的图书馆架设互相借阅的服务器
3。对于借阅的问题
现在要做成各个馆的图书可以互相借阅，并且可以在任意一个馆归还图书。
这个我理解应该是，我在 A 图书馆办理借书证，要借 B 图书馆的书，那么应该不是这种，提交请求，B图书馆送书过来，
最简单应该是我在 A 图书馆查询是否有这本书，然后得知在 B，于是去 B 借阅。
那么服务器需要做的是，查询功能，以及存储，你说借阅的书可以在 C 图书馆换，那么互相借阅的记录要解决两个问题
第一 B 图书馆保存 A 图书馆用户借阅该书信息
第二 服务器保存 B 借阅信息 ID 以及，A 图书馆用户 ID
保存之后在 C 图书馆可以在服务器查询到 A 图书馆用户信息，与 B 图书馆书籍信息，提供还书服务，通知 B 图书馆修改书籍态，服务器保存该图书在 C 图书馆，归还后删除，以及通知 A 图书馆用户已经把书归还，借阅书籍数量减少
那么需要已经有的图书馆系统提供书籍借阅接口，用户接口，书籍查询接口
还需要可以保存其他图书馆用户借阅本图书馆书籍信息
对于*服务器可以设双服务器，并行存储
#4
*服务器另外一个问题是系统的规模和性能一般就限于*服务器的性能了。
所以，能避免则避免 。。。
#5
如果做成*集权的系统，首先商务上你能hold住吗？如果能，倒是可以一试，毕竟上线后管理、维护起来都十分方便，不用到处跑。至于性能、故障之类的问题，不管哪种架构都会有，假设你做成多套，一个馆一套系统，那各个馆的单个系统不也存在故障问题么？如果系统就部署在各个馆内，到时候维护起来岂不是更麻烦？
如果做成多系统架构，则可以作一个统一的数据管理和共享平台，为用户提供统一的界面，上面提供各个图书馆系统的链接，用户一点，就进入到目标图书馆的系统，这样在业务上拓展起来很方便，你只要做个系统，把各个图书馆的系统注册进来即可。
没有完美的方案，只有最适合的方案。综合考虑商务、业务、开发、部署、维护、成本等因素，哪种架构的综合权值最高，则这种方案就是最优的。
如果做成多系统架构，则可以作一个统一的数据管理和共享平台，为用户提供统一的界面，上面提供各个图书馆系统的链接，用户一点，就进入到目标图书馆的系统，这样在业务上拓展起来很方便，你只要做个系统，把各个图书馆的系统注册进来即可。
没有完美的方案，只有最适合的方案。综合考虑商务、业务、开发、部署、维护、成本等因素，哪种架构的综合权值最高，则这种方案就是最优的。
#6
其实也是，这些因素根本就不是技术所能控制的。
#7
楼主你这是纯技术性探讨问题还是现实问题？
你提到“每个图书馆都有相同的借书系统”，让我感觉很像是个 纯技术性探讨问题，因为现实情况基本无法保证这一点，尤其是当有更多的图书馆加入这个“通借联盟”的情况下。
一般来说，从现实角度出发，银联是这类系统的典范代表。
◎ 各个银行就是各个图书馆，没有银联它们也要能独立正常运作；（所以你提及的所有借书都要发到*服务器，不合理）
◎ 当发生跨馆借阅时，有点类似于跨行取款，银联要负责跟发卡行（给该借阅人发借书卡的图书馆）进行沟通，确认比如：是不是已经无效、挂失、还有多少借书额度、有没有超期未归还等等；
◎ 银联跟发卡行锁定一本书的借阅额度；
◎ 当前图书馆执行具体借阅处理等，然后让银联通知发卡行确定扣减借阅额度；
◎ 上述过程银联记录所有交易日志并定期对账（半天或一天），及提供后期查帐。
从纯技术性探讨而言，一个跨多个机构的分布式系统，关键业务居然存在单点依赖（*服务器），也极其不合理。
总体来，应该使用：*分布式模型，或者彻底分布式模型。
你提到“每个图书馆都有相同的借书系统”，让我感觉很像是个 纯技术性探讨问题，因为现实情况基本无法保证这一点，尤其是当有更多的图书馆加入这个“通借联盟”的情况下。
一般来说，从现实角度出发，银联是这类系统的典范代表。
◎ 各个银行就是各个图书馆，没有银联它们也要能独立正常运作；（所以你提及的所有借书都要发到*服务器，不合理）
◎ 当发生跨馆借阅时，有点类似于跨行取款，银联要负责跟发卡行（给该借阅人发借书卡的图书馆）进行沟通，确认比如：是不是已经无效、挂失、还有多少借书额度、有没有超期未归还等等；
◎ 银联跟发卡行锁定一本书的借阅额度；
◎ 当前图书馆执行具体借阅处理等，然后让银联通知发卡行确定扣减借阅额度；
◎ 上述过程银联记录所有交易日志并定期对账（半天或一天），及提供后期查帐。
从纯技术性探讨而言，一个跨多个机构的分布式系统，关键业务居然存在单点依赖（*服务器），也极其不合理。
总体来，应该使用：*分布式模型，或者彻底分布式模型。
#8
是现实问题啊，这里说的各个图书馆，是某个市的所有图书馆，现在的图书馆都是这种模式。目前我们公司就是这样的，而且也是按照我说的这样设计的，我就想问下，这样合不合理，还有没有更好的。
#9
商务上不用考虑的，因为现在的前提就是全市所有的图书馆都用我们的系统，我们的系统是不与其他系统做接口通信的。
#10
我说下我们目前这种设计的优点吧：
1、肯定是可以满足需求的，即各个图书馆的图书可以互相借阅。
2、*服务器宕机的话，目前是这样处理的，本地写离线记录，然后等*服务器恢复后，上传上去。
3、某个图书馆本地的系统宕机后，也不会影响其他馆的系统，仅仅是本馆不能借阅了。
#11
你说的不是设计优点，是设计这类跨地区分布式系统必须确保的能力。其中故障最小化或者说故障不扩散，是这类系统核心要考虑的问题。
你提及的：本地写离线记录这个策略是可以的。
我个人而言，总体仍然建议是：*分布式模型，*以数据集中为主，地方以业务快速处理为主。
◎ 也即首先考虑地方系统可独立运行，然后准实时方式将借阅数据同步给*服务器；（这样无论是*宕机还是不宕机，系统整体运作机制不变）；
◎ 发生跨馆借阅则由*服务器作为协调者（类似银联），但数据以地方服务器发生为主，*继续保持的准实时方式得到最终数据；
◎ 这样*可以满足各类查询统计需求的同时，不必配置高规格服务器资源，因为主体业务处理还是地方；
◎ *不容易变成瓶颈点，尤其是发生远程通讯网络速度不好，或者*服务器有些卡之类问题是，影响不是全局性的；
◎ 帐号数据，如果打算*集中管理，是可以考虑的；因为该业务不频密；不过最好也是做好规则，各地可独立管理，准实时同步给*服务器；
◎ 第三方图书馆系统如果想加入联盟，只要遵循你们所制定的*服务器的协议标准，并缴纳一点点费用，就可以加入；从此你们变成平台运营商和标准制定者；
◎ 哪天你们把图书馆借阅证做到跨省了，这系统就威武了。
我始终认为：设计都是源于现实社会的，想想现在高院、省院和地方法院的关系是啥？
#12
这个问题的前提是有区域性的，就是某个地区的所有图书馆，一般也就十多个。而且都会用我们的系统。
#13
原来我是个架构小白，这个“*分布式模型”是个什么模型？百度了下，没有相关资料。
#14
差不多看懂你说的了，不过还是会存在一些问题。
你这里说的，中心服务器只是作为一个数据中心，具体的业务由本地来做。但是如果读者或者图书不是本馆的话，这样就没法做了。因为借书时会针对读者类型和图书类型做一些规则验证的，而这里的读者类型和图书类型就必须要到中心服务器去查了，这样通信起来比较麻烦，也存在一些不确定性。
#15
活学活用。
就是*处理高层次的事情，地方处理低层次的事情。。。
举个简单的例子吧，大家都是有户口的概念的，有些事情，只能去户口所在地处理。。。
借书这事，你也可以想想，书是不是也有个所属馆。。。
#16
应该没有该名称。只是我简单对这个模式做的名字。
在我们实际系统中，它的模式名字叫做：“*集中，两级部署”，不过是*系统，所以地域广泛点点。
其实不要太介意于“局限于某地区”这个命题，业务是会变化的，跨市甚至跨省借阅，信用管理、押金管理，为VIP用户提供送书上门、归还上门等服务也都是可能的。
另外就是：当前业务规模下，系统复杂度和可扩展性与其投资收益是存在关系的，不见得一味追求极强扩展性架构。在这个命题下，单一大集中系统（不是指你这个，而是指真的全局性一套）是很有性价比优势的，风险当然是单点故障问题。
最后：这些个图书馆有一个统一上级机构么？你们的*服务器最终隶属于谁负责管理？谁有资格维护这么多书籍和个人信息的这个数据库？这个系统的密级是怎么定的？——以上问题纯属好奇，不答也罢。
#17
这个取决于*库是否要将全局帐号信息和书目信息下发到各地方做查询库。
我们实际系统中是有的，叫做：清分库；将一些全局性能增快业务本地化处理的数据，由*数据库清分给各地。
#18
同意
从高可用少维护的角度来说：
*系统无须保存全局书与用户信息
下面说明张三借书场景及系统业务逻辑
借书：
张三去a门店借书《软件程序设计》，这时a门店系统首先在自己系统内查找没找到，这时*系统从已经注册过门店系统中查找可借用书籍，在b店找到后返回该门店信息、书本信息，这时张三立马决定借下来，*系统保存下借出书籍数据，并调用b店借书接口完成系统上的借书操作（b店可根据*系统调用的借书接口中获取用户信息将书快递给张三）
还书：
张三这次出差到了h市，书在出差途中车上刚好也看完了，于是就是进了h门店准备还书，h门店系统首先还是从自己系统内查找已借书记录，肯定是没查到，然后从*系统中查找，找到后返回该书的借书信息（a店借的书，b店快递的书，借书人信息），h店拿到书后快递给b店，*系统调用b店还书接口并附上快递单号，至此完成还书操作。
这样设计要加的功能：
1.在每个分店系统上增加查询书信息的接口、借书、还书接口供*系统调用；
2.将该门店信息系统注册到*系统；
3.*系统只需保存借书、还书籍数据。
这样设计的优点：
1.不必维护大数据，保证用户信息安全；
2.不影响分店系统内部的正常操作，分店断网，*系统宕机都可以正常使用；
缺点：
1.老的分店系统须添加接口
不足的地方欢迎补充拍砖！
从高可用少维护的角度来说：
*系统无须保存全局书与用户信息
下面说明张三借书场景及系统业务逻辑
借书：
张三去a门店借书《软件程序设计》，这时a门店系统首先在自己系统内查找没找到，这时*系统从已经注册过门店系统中查找可借用书籍，在b店找到后返回该门店信息、书本信息，这时张三立马决定借下来，*系统保存下借出书籍数据，并调用b店借书接口完成系统上的借书操作（b店可根据*系统调用的借书接口中获取用户信息将书快递给张三）
还书：
张三这次出差到了h市，书在出差途中车上刚好也看完了，于是就是进了h门店准备还书，h门店系统首先还是从自己系统内查找已借书记录，肯定是没查到，然后从*系统中查找，找到后返回该书的借书信息（a店借的书，b店快递的书，借书人信息），h店拿到书后快递给b店，*系统调用b店还书接口并附上快递单号，至此完成还书操作。
这样设计要加的功能：
1.在每个分店系统上增加查询书信息的接口、借书、还书接口供*系统调用；
2.将该门店信息系统注册到*系统；
3.*系统只需保存借书、还书籍数据。
这样设计的优点：
1.不必维护大数据，保证用户信息安全；
2.不影响分店系统内部的正常操作，分店断网，*系统宕机都可以正常使用；
缺点：
1.老的分店系统须添加接口
不足的地方欢迎补充拍砖！
#19
额，可能我没说清楚。
你的借书场景是不会出现的。
不知道你有没有去图书馆借过书，借书的前提是读者手里先拿到所需要借的书，然后才到借书处进行登记外借手续的。你说的这种场景差不多算是图书馆的另一个业务。
你的借书场景是不会出现的。
不知道你有没有去图书馆借过书，借书的前提是读者手里先拿到所需要借的书，然后才到借书处进行登记外借手续的。你说的这种场景差不多算是图书馆的另一个业务。
#20
哈哈。那我还是不答了。
上面说了，虽然有很多图书馆，但肯定是有一个老大的。
比如一个市，肯定有个市馆的，然后一个市一般会划分为几个区，每个区也会有图书馆的。
*服务器的数据其实会给各个馆都开通权限的，可以各自维护各自馆的数据。
#21
市馆和区馆又不是行政上的从属关系。。。。
#22
谢谢楼主20楼的分享，最后总结下俺的观点：
1、架构设计不能脱离用户需求和实际投资收益比，因此总的来说是满足用户需求的前提下，适当考虑可扩展性或适配性，选择投资收益比合适的。
2、如果本系统仅局限于一个地市内的多个图书馆，我认为：单一大集中系统就已经够了，实际上很多*机构（社保、税务、园林等）早就已经实现市级（部分省级）的单一大集中系统，也就是冒着单点故障的风险集中建设，各区并无服务器配置；这种模式总体投资小，在强化*集中系统的容错能力后，全系统就可以很好了。毕竟社保、税务都是涉及大量钱的收入问题，跟图书馆不是2个数量级以内。
3、你提出的模式，在后面10楼你补充了“本地写离线记录”这种应急机制之后，我认为复杂度已经提升了不少，稍作演进可能就跟我提及那种复杂度差不多了；老实说，我觉得对于一个地市级系统来说，投资收益比不怎么合适。
4、总的来说俺的观点大致是：地市级以下直接单一大集中；省级以上直接考虑*集中两级部署；具体策略视可用性要求和投资规模。
1、架构设计不能脱离用户需求和实际投资收益比，因此总的来说是满足用户需求的前提下，适当考虑可扩展性或适配性，选择投资收益比合适的。
2、如果本系统仅局限于一个地市内的多个图书馆，我认为：单一大集中系统就已经够了，实际上很多*机构（社保、税务、园林等）早就已经实现市级（部分省级）的单一大集中系统，也就是冒着单点故障的风险集中建设，各区并无服务器配置；这种模式总体投资小，在强化*集中系统的容错能力后，全系统就可以很好了。毕竟社保、税务都是涉及大量钱的收入问题，跟图书馆不是2个数量级以内。
3、你提出的模式，在后面10楼你补充了“本地写离线记录”这种应急机制之后，我认为复杂度已经提升了不少，稍作演进可能就跟我提及那种复杂度差不多了；老实说，我觉得对于一个地市级系统来说，投资收益比不怎么合适。
4、总的来说俺的观点大致是：地市级以下直接单一大集中；省级以上直接考虑*集中两级部署；具体策略视可用性要求和投资规模。
#23
感觉楼主业务考虑的稍稍复杂了一点，虽然是多个图书馆，但通过你描述的需求，你可以把图书馆看成一个属性就可以了
#24
个人认为，你可以给你的借阅程序做一个对外的接口。就好像支付宝跟银行一样，支付宝通过接口访问银行的数据。如果你有很多图书馆，如果想在馆A借馆B的书，通过接口访问馆B就可以了。这样可以避免单点故障，而且实现数据共享
#25
楼主 思想是好的，建议多考虑它的实际情况。
#1 如果是在现有的系统上做扩展,不建议这样做,成本高，难度高，原始逻辑破坏性高。建议 只在条件限定上做扩展或重写.
#2 如果是自己做一个新系统,可以 只是 在这个模型中 一旦建立了*服务器 就得考虑 服务器集群的逻辑关系, 让每个服务器处理自己该处理的任务,是不是每个请求都是直接发送到 *服务器的.
#26
楼主这个方案是可行的，也是方便维护的一种很好的方式。给楼主一个建议就是可以通过报文同步的方式将中心数据同步到各个子图书馆，或者子图书馆向中心同步数据，这样中心与各子图书馆的程序都是一样的，方便维护与管理。
#27
该回复于2014-09-18 13:21:05被管理员删除
#1
如果整体系统都是自己做的话，一种是做成一套系统。
还有一种是做成多套，每本书都有个归属图书馆的概念，书号中用2-3位表示归属图书馆。
对书而言，增加一个所在地，还有一个叫馆借的状态。
*服务器的话，其实有点复杂，万一当机，影响也比较大，能不用就不用。
还有一种是做成多套，每本书都有个归属图书馆的概念，书号中用2-3位表示归属图书馆。
对书而言，增加一个所在地，还有一个叫馆借的状态。
*服务器的话，其实有点复杂，万一当机，影响也比较大，能不用就不用。
#2
*服务器宕机的话，是考虑本地写离线记录，等*服务器恢复后，上传上去。
#3
1。现在应该是每个图书馆都有自己的系统，不会都换，那么就需要调用已经存在系统的接口
2。调用原有系统最小修改的方法还是在最大的图书馆架设互相借阅的服务器
3。对于借阅的问题
现在要做成各个馆的图书可以互相借阅，并且可以在任意一个馆归还图书。
这个我理解应该是，我在 A 图书馆办理借书证，要借 B 图书馆的书，那么应该不是这种，提交请求，B图书馆送书过来，
最简单应该是我在 A 图书馆查询是否有这本书，然后得知在 B，于是去 B 借阅。
那么服务器需要做的是，查询功能，以及存储，你说借阅的书可以在 C 图书馆换，那么互相借阅的记录要解决两个问题
第一 B 图书馆保存 A 图书馆用户借阅该书信息
第二 服务器保存 B 借阅信息 ID 以及，A 图书馆用户 ID
保存之后在 C 图书馆可以在服务器查询到 A 图书馆用户信息，与 B 图书馆书籍信息，提供还书服务，通知 B 图书馆修改书籍态，服务器保存该图书在 C 图书馆，归还后删除，以及通知 A 图书馆用户已经把书归还，借阅书籍数量减少
那么需要已经有的图书馆系统提供书籍借阅接口，用户接口，书籍查询接口
还需要可以保存其他图书馆用户借阅本图书馆书籍信息
对于*服务器可以设双服务器，并行存储
2。调用原有系统最小修改的方法还是在最大的图书馆架设互相借阅的服务器
3。对于借阅的问题
现在要做成各个馆的图书可以互相借阅，并且可以在任意一个馆归还图书。
这个我理解应该是，我在 A 图书馆办理借书证，要借 B 图书馆的书，那么应该不是这种，提交请求，B图书馆送书过来，
最简单应该是我在 A 图书馆查询是否有这本书，然后得知在 B，于是去 B 借阅。
那么服务器需要做的是，查询功能，以及存储，你说借阅的书可以在 C 图书馆换，那么互相借阅的记录要解决两个问题
第一 B 图书馆保存 A 图书馆用户借阅该书信息
第二 服务器保存 B 借阅信息 ID 以及，A 图书馆用户 ID
保存之后在 C 图书馆可以在服务器查询到 A 图书馆用户信息，与 B 图书馆书籍信息，提供还书服务，通知 B 图书馆修改书籍态，服务器保存该图书在 C 图书馆，归还后删除，以及通知 A 图书馆用户已经把书归还，借阅书籍数量减少
那么需要已经有的图书馆系统提供书籍借阅接口，用户接口，书籍查询接口
还需要可以保存其他图书馆用户借阅本图书馆书籍信息
对于*服务器可以设双服务器，并行存储
#4
*服务器另外一个问题是系统的规模和性能一般就限于*服务器的性能了。
所以，能避免则避免 。。。
#5
如果做成*集权的系统，首先商务上你能hold住吗？如果能，倒是可以一试，毕竟上线后管理、维护起来都十分方便，不用到处跑。至于性能、故障之类的问题，不管哪种架构都会有，假设你做成多套，一个馆一套系统，那各个馆的单个系统不也存在故障问题么？如果系统就部署在各个馆内，到时候维护起来岂不是更麻烦？
如果做成多系统架构，则可以作一个统一的数据管理和共享平台，为用户提供统一的界面，上面提供各个图书馆系统的链接，用户一点，就进入到目标图书馆的系统，这样在业务上拓展起来很方便，你只要做个系统，把各个图书馆的系统注册进来即可。
没有完美的方案，只有最适合的方案。综合考虑商务、业务、开发、部署、维护、成本等因素，哪种架构的综合权值最高，则这种方案就是最优的。
如果做成多系统架构，则可以作一个统一的数据管理和共享平台，为用户提供统一的界面，上面提供各个图书馆系统的链接，用户一点，就进入到目标图书馆的系统，这样在业务上拓展起来很方便，你只要做个系统，把各个图书馆的系统注册进来即可。
没有完美的方案，只有最适合的方案。综合考虑商务、业务、开发、部署、维护、成本等因素，哪种架构的综合权值最高，则这种方案就是最优的。
#6
其实也是，这些因素根本就不是技术所能控制的。
#7
楼主你这是纯技术性探讨问题还是现实问题？
你提到“每个图书馆都有相同的借书系统”，让我感觉很像是个 纯技术性探讨问题，因为现实情况基本无法保证这一点，尤其是当有更多的图书馆加入这个“通借联盟”的情况下。
一般来说，从现实角度出发，银联是这类系统的典范代表。
◎ 各个银行就是各个图书馆，没有银联它们也要能独立正常运作；（所以你提及的所有借书都要发到*服务器，不合理）
◎ 当发生跨馆借阅时，有点类似于跨行取款，银联要负责跟发卡行（给该借阅人发借书卡的图书馆）进行沟通，确认比如：是不是已经无效、挂失、还有多少借书额度、有没有超期未归还等等；
◎ 银联跟发卡行锁定一本书的借阅额度；
◎ 当前图书馆执行具体借阅处理等，然后让银联通知发卡行确定扣减借阅额度；
◎ 上述过程银联记录所有交易日志并定期对账（半天或一天），及提供后期查帐。
从纯技术性探讨而言，一个跨多个机构的分布式系统，关键业务居然存在单点依赖（*服务器），也极其不合理。
总体来，应该使用：*分布式模型，或者彻底分布式模型。
你提到“每个图书馆都有相同的借书系统”，让我感觉很像是个 纯技术性探讨问题，因为现实情况基本无法保证这一点，尤其是当有更多的图书馆加入这个“通借联盟”的情况下。
一般来说，从现实角度出发，银联是这类系统的典范代表。
◎ 各个银行就是各个图书馆，没有银联它们也要能独立正常运作；（所以你提及的所有借书都要发到*服务器，不合理）
◎ 当发生跨馆借阅时，有点类似于跨行取款，银联要负责跟发卡行（给该借阅人发借书卡的图书馆）进行沟通，确认比如：是不是已经无效、挂失、还有多少借书额度、有没有超期未归还等等；
◎ 银联跟发卡行锁定一本书的借阅额度；
◎ 当前图书馆执行具体借阅处理等，然后让银联通知发卡行确定扣减借阅额度；
◎ 上述过程银联记录所有交易日志并定期对账（半天或一天），及提供后期查帐。
从纯技术性探讨而言，一个跨多个机构的分布式系统，关键业务居然存在单点依赖（*服务器），也极其不合理。
总体来，应该使用：*分布式模型，或者彻底分布式模型。
#8
是现实问题啊，这里说的各个图书馆，是某个市的所有图书馆，现在的图书馆都是这种模式。目前我们公司就是这样的，而且也是按照我说的这样设计的，我就想问下，这样合不合理，还有没有更好的。
#9
商务上不用考虑的，因为现在的前提就是全市所有的图书馆都用我们的系统，我们的系统是不与其他系统做接口通信的。
#10
我说下我们目前这种设计的优点吧：
1、肯定是可以满足需求的，即各个图书馆的图书可以互相借阅。
2、*服务器宕机的话，目前是这样处理的，本地写离线记录，然后等*服务器恢复后，上传上去。
3、某个图书馆本地的系统宕机后，也不会影响其他馆的系统，仅仅是本馆不能借阅了。
#11
你说的不是设计优点，是设计这类跨地区分布式系统必须确保的能力。其中故障最小化或者说故障不扩散，是这类系统核心要考虑的问题。
你提及的：本地写离线记录这个策略是可以的。
我个人而言，总体仍然建议是：*分布式模型，*以数据集中为主，地方以业务快速处理为主。
◎ 也即首先考虑地方系统可独立运行，然后准实时方式将借阅数据同步给*服务器；（这样无论是*宕机还是不宕机，系统整体运作机制不变）；
◎ 发生跨馆借阅则由*服务器作为协调者（类似银联），但数据以地方服务器发生为主，*继续保持的准实时方式得到最终数据；
◎ 这样*可以满足各类查询统计需求的同时，不必配置高规格服务器资源，因为主体业务处理还是地方；
◎ *不容易变成瓶颈点，尤其是发生远程通讯网络速度不好，或者*服务器有些卡之类问题是，影响不是全局性的；
◎ 帐号数据，如果打算*集中管理，是可以考虑的；因为该业务不频密；不过最好也是做好规则，各地可独立管理，准实时同步给*服务器；
◎ 第三方图书馆系统如果想加入联盟，只要遵循你们所制定的*服务器的协议标准，并缴纳一点点费用，就可以加入；从此你们变成平台运营商和标准制定者；
◎ 哪天你们把图书馆借阅证做到跨省了，这系统就威武了。
我始终认为：设计都是源于现实社会的，想想现在高院、省院和地方法院的关系是啥？
#12
这个问题的前提是有区域性的，就是某个地区的所有图书馆，一般也就十多个。而且都会用我们的系统。
#13
原来我是个架构小白，这个“*分布式模型”是个什么模型？百度了下，没有相关资料。
#14
差不多看懂你说的了，不过还是会存在一些问题。
你这里说的，中心服务器只是作为一个数据中心，具体的业务由本地来做。但是如果读者或者图书不是本馆的话，这样就没法做了。因为借书时会针对读者类型和图书类型做一些规则验证的，而这里的读者类型和图书类型就必须要到中心服务器去查了，这样通信起来比较麻烦，也存在一些不确定性。
#15
活学活用。
就是*处理高层次的事情，地方处理低层次的事情。。。
举个简单的例子吧，大家都是有户口的概念的，有些事情，只能去户口所在地处理。。。
借书这事，你也可以想想，书是不是也有个所属馆。。。
#16
应该没有该名称。只是我简单对这个模式做的名字。
在我们实际系统中，它的模式名字叫做：“*集中，两级部署”，不过是*系统，所以地域广泛点点。
其实不要太介意于“局限于某地区”这个命题，业务是会变化的，跨市甚至跨省借阅，信用管理、押金管理，为VIP用户提供送书上门、归还上门等服务也都是可能的。
另外就是：当前业务规模下，系统复杂度和可扩展性与其投资收益是存在关系的，不见得一味追求极强扩展性架构。在这个命题下，单一大集中系统（不是指你这个，而是指真的全局性一套）是很有性价比优势的，风险当然是单点故障问题。
最后：这些个图书馆有一个统一上级机构么？你们的*服务器最终隶属于谁负责管理？谁有资格维护这么多书籍和个人信息的这个数据库？这个系统的密级是怎么定的？——以上问题纯属好奇，不答也罢。
#17
这个取决于*库是否要将全局帐号信息和书目信息下发到各地方做查询库。
我们实际系统中是有的，叫做：清分库；将一些全局性能增快业务本地化处理的数据，由*数据库清分给各地。
#18
同意
从高可用少维护的角度来说：
*系统无须保存全局书与用户信息
下面说明张三借书场景及系统业务逻辑
借书：
张三去a门店借书《软件程序设计》，这时a门店系统首先在自己系统内查找没找到，这时*系统从已经注册过门店系统中查找可借用书籍，在b店找到后返回该门店信息、书本信息，这时张三立马决定借下来，*系统保存下借出书籍数据，并调用b店借书接口完成系统上的借书操作（b店可根据*系统调用的借书接口中获取用户信息将书快递给张三）
还书：
张三这次出差到了h市，书在出差途中车上刚好也看完了，于是就是进了h门店准备还书，h门店系统首先还是从自己系统内查找已借书记录，肯定是没查到，然后从*系统中查找，找到后返回该书的借书信息（a店借的书，b店快递的书，借书人信息），h店拿到书后快递给b店，*系统调用b店还书接口并附上快递单号，至此完成还书操作。
这样设计要加的功能：
1.在每个分店系统上增加查询书信息的接口、借书、还书接口供*系统调用；
2.将该门店信息系统注册到*系统；
3.*系统只需保存借书、还书籍数据。
这样设计的优点：
1.不必维护大数据，保证用户信息安全；
2.不影响分店系统内部的正常操作，分店断网，*系统宕机都可以正常使用；
缺点：
1.老的分店系统须添加接口
不足的地方欢迎补充拍砖！
从高可用少维护的角度来说：
*系统无须保存全局书与用户信息
下面说明张三借书场景及系统业务逻辑
借书：
张三去a门店借书《软件程序设计》，这时a门店系统首先在自己系统内查找没找到，这时*系统从已经注册过门店系统中查找可借用书籍，在b店找到后返回该门店信息、书本信息，这时张三立马决定借下来，*系统保存下借出书籍数据，并调用b店借书接口完成系统上的借书操作（b店可根据*系统调用的借书接口中获取用户信息将书快递给张三）
还书：
张三这次出差到了h市，书在出差途中车上刚好也看完了，于是就是进了h门店准备还书，h门店系统首先还是从自己系统内查找已借书记录，肯定是没查到，然后从*系统中查找，找到后返回该书的借书信息（a店借的书，b店快递的书，借书人信息），h店拿到书后快递给b店，*系统调用b店还书接口并附上快递单号，至此完成还书操作。
这样设计要加的功能：
1.在每个分店系统上增加查询书信息的接口、借书、还书接口供*系统调用；
2.将该门店信息系统注册到*系统；
3.*系统只需保存借书、还书籍数据。
这样设计的优点：
1.不必维护大数据，保证用户信息安全；
2.不影响分店系统内部的正常操作，分店断网，*系统宕机都可以正常使用；
缺点：
1.老的分店系统须添加接口
不足的地方欢迎补充拍砖！
#19
额，可能我没说清楚。
你的借书场景是不会出现的。
不知道你有没有去图书馆借过书，借书的前提是读者手里先拿到所需要借的书，然后才到借书处进行登记外借手续的。你说的这种场景差不多算是图书馆的另一个业务。
你的借书场景是不会出现的。
不知道你有没有去图书馆借过书，借书的前提是读者手里先拿到所需要借的书，然后才到借书处进行登记外借手续的。你说的这种场景差不多算是图书馆的另一个业务。
#20
哈哈。那我还是不答了。
上面说了，虽然有很多图书馆，但肯定是有一个老大的。
比如一个市，肯定有个市馆的，然后一个市一般会划分为几个区，每个区也会有图书馆的。
*服务器的数据其实会给各个馆都开通权限的，可以各自维护各自馆的数据。
#21
市馆和区馆又不是行政上的从属关系。。。。
#22
谢谢楼主20楼的分享，最后总结下俺的观点：
1、架构设计不能脱离用户需求和实际投资收益比，因此总的来说是满足用户需求的前提下，适当考虑可扩展性或适配性，选择投资收益比合适的。
2、如果本系统仅局限于一个地市内的多个图书馆，我认为：单一大集中系统就已经够了，实际上很多*机构（社保、税务、园林等）早就已经实现市级（部分省级）的单一大集中系统，也就是冒着单点故障的风险集中建设，各区并无服务器配置；这种模式总体投资小，在强化*集中系统的容错能力后，全系统就可以很好了。毕竟社保、税务都是涉及大量钱的收入问题，跟图书馆不是2个数量级以内。
3、你提出的模式，在后面10楼你补充了“本地写离线记录”这种应急机制之后，我认为复杂度已经提升了不少，稍作演进可能就跟我提及那种复杂度差不多了；老实说，我觉得对于一个地市级系统来说，投资收益比不怎么合适。
4、总的来说俺的观点大致是：地市级以下直接单一大集中；省级以上直接考虑*集中两级部署；具体策略视可用性要求和投资规模。
1、架构设计不能脱离用户需求和实际投资收益比，因此总的来说是满足用户需求的前提下，适当考虑可扩展性或适配性，选择投资收益比合适的。
2、如果本系统仅局限于一个地市内的多个图书馆，我认为：单一大集中系统就已经够了，实际上很多*机构（社保、税务、园林等）早就已经实现市级（部分省级）的单一大集中系统，也就是冒着单点故障的风险集中建设，各区并无服务器配置；这种模式总体投资小，在强化*集中系统的容错能力后，全系统就可以很好了。毕竟社保、税务都是涉及大量钱的收入问题，跟图书馆不是2个数量级以内。
3、你提出的模式，在后面10楼你补充了“本地写离线记录”这种应急机制之后，我认为复杂度已经提升了不少，稍作演进可能就跟我提及那种复杂度差不多了；老实说，我觉得对于一个地市级系统来说，投资收益比不怎么合适。
4、总的来说俺的观点大致是：地市级以下直接单一大集中；省级以上直接考虑*集中两级部署；具体策略视可用性要求和投资规模。
#23
感觉楼主业务考虑的稍稍复杂了一点，虽然是多个图书馆，但通过你描述的需求，你可以把图书馆看成一个属性就可以了
#24
个人认为，你可以给你的借阅程序做一个对外的接口。就好像支付宝跟银行一样，支付宝通过接口访问银行的数据。如果你有很多图书馆，如果想在馆A借馆B的书，通过接口访问馆B就可以了。这样可以避免单点故障，而且实现数据共享
#25
楼主 思想是好的，建议多考虑它的实际情况。
#1 如果是在现有的系统上做扩展,不建议这样做,成本高，难度高，原始逻辑破坏性高。建议 只在条件限定上做扩展或重写.
#2 如果是自己做一个新系统,可以 只是 在这个模型中 一旦建立了*服务器 就得考虑 服务器集群的逻辑关系, 让每个服务器处理自己该处理的任务,是不是每个请求都是直接发送到 *服务器的.
#26
楼主这个方案是可行的，也是方便维护的一种很好的方式。给楼主一个建议就是可以通过报文同步的方式将中心数据同步到各个子图书馆，或者子图书馆向中心同步数据，这样中心与各子图书馆的程序都是一样的，方便维护与管理。
#27
该回复于2014-09-18 13:21:05被管理员删除