如题,需求如下:
通过短信的菜单导航,用户在办理业务时,需要通过短信和服务器进行多次请求交互,如何维护用户的上下文?
短信的Session如何处理?
哪位牛人有类似的项目经验,可以分享一下,谢谢!
问题补充
将session 信息放入memcached,设定一个过期的时间。
取不到数据就说明没 session 了
话说你画的图中,整个查询都是无状态的,为啥要session
业务是一步一步交互,现在的需求是每个步骤的编码均是
01. xxx
02. xxx
这样,就需要在服务器端维护一个会话,来记录用户交互的上下文,
在真正处理具体业务时,需要从上下文中把操作的记录代码拼装起来,如 01 + 02 + 01 = 010201=最终的编码,
现在问题在于这些操作记录是否要放到session中维护?
问题补充
01. xxx
02. xxx
这样,就需要在服务器端维护一个会话,来记录用户交互的上下文,
在真正处理具体业务时,需要从上下文中把操作的记录代码拼装起来,如 01 + 02 + 01 = 010201=最终的编码,
现在问题在于这些操作记录是否要放到session中维护?
可是你图片中的例子不是这样子的,把图片放这里不是误导大家吗
这样的需求当然要session了,可以把session放数据库里或者放到某种缓存中间件里。
不好意思,那是引用别人的图片……
我的初步想法是把session放到内存中,相当于放到缓存中,session 需要持久化到数据库中么?
持久化的目的是什么? 我也在衡量这两个方式的利弊。
谢谢。
问题补充
短信本身是无状态的,维持会话不太容易
不好意思,好像不是这个技术……
就是短信营业厅的使用,用短信交互来办理业务。
问题补充
正在看小丁的比赛,紧张啊,抽空说明一下,
我也是这样想的,但是不知道session是否要持久化到数据化? 有什么准则或者依据么?谢谢
问题补充
首先短信是无状态的,另除了像一些什么活动会有所谓的上下文,如看名字好不好的。。。一步步引诱你。
像移动的短信菜单,都是固定的数字(唯一的),不存在很复杂的上下文。
数据保存到数据库比较好,记录下办理的是什么业务,记录到哪一步了。
你好,我也认为将上下文放到session里,但不确定session是否要持久化?操作记录是否要持久化?
目前唯一确定的是将最终办理业务的那个操作记录(01)持久化到数据库(如 01 - 02 -01 01是开通XX业务),但是操作记录…… 有的没有什么参考意义,是否有必要持久化到数据库?谢谢
问题补充
可以使用子端口来代替
比如:用户发0到10086,你可以使用100861回复短信给用,提示他回复1到100861确认办法里
实在没办法才考虑保存用户的会话状态
你好,因为需求是要让用户操作的代码简单,就是将用户回复的代码都定义为 01,02,03 这样简短的编号,所以维护上下文应该是必要的,第二,回复100861不太符合需求,因为用户从头到尾都是回复到10086的……
谢谢
问题补充
首先短信是无状态的,另除了像一些什么活动会有所谓的上下文,如看名字好不好的。。。一步步引诱你。
像移动的短信菜单,都是固定的数字(唯一的),不存在很复杂的上下文。
数据保存到数据库比较好,记录下办理的是什么业务,记录到哪一步了。
还请您把你的处理的具体方法分享出来,谢谢!
问题补充
额…… 这个就不知道了,只负责前期的设计,可以简单描述下你们的概要设计结构不?谢谢
问题补充
key是session+服务ID,尤其是你在用10086这种共用号码提供多种服务的时候,比如
回复1#1到10086进入订阅彩玲流程
回复2#1到10086进入订阅流量流程
这两个流程随着后续的交互可以做到让客户同时进行,所以session+服务ID是比较合理的
用户的回复可能会重复、甚至是无顺序的,所以用有限状态机的模式去处理
比如你期待用户回复的顺序是1#1 -> 1#2 -> 1#3 -> 完成
用户可能回复的顺序是:1#1 -> 1#1 -> 1#3
甚至可能试:1#3
专门开几个线程去处理会话超时的情况
当短信厅联不上mas的时候就别企图立即重试,进行延时稍候再次进行重试。注意处理好短信业务超时的关系。
谢谢你的回复,我好好思考一下
问题补充
用户第一次发“CX:用户号码”到10086,即第一次上行短信,当接受到该上行短信时
随机生成一串数字,比如84097,将其加到10086后面作为下行号码。
第一次下行短信回复“回复1#查询什么什么,回复2#查询什么什么...”;
这时1008684097就是该用户本次的sessionId,至于业务信息自己存来。
如果需求必须是“回复1#到10086查询什么什么,回复2#到10086查询什么什么”的话,就
想想其它办法吧,目前我们是类似按照前面说的这么干的。
目前的需求就是“回复1#到10086查询什么什么,回复2#到10086查询什么什么”,目的是让用户尽量少输入,提高用户体验,不过你说的这种思路挺好,可以跟领导沟通一下。
按你的思路,每个用户每一次操作都会建立一个下行号码?从而用户每次的回复号码都不一样?
再发散一下,能不能每次请求的一个业务建立一个下行号码?而不是每次请求都建立一个号码……
这样可以将不同业务隔离开,实现用户同时并行办理多个业务。
问题补充
EJB的session bean
memcached
内存表
随便选一个,别放在web session里,依赖太大
应该会采用 memcached 或者 内存表 ,只保留在内存中不可靠,系统重启就什么都没有了……所以持久化应该是必要的
但是需要持久化哪些内容?
系统没有依赖web,只是想模拟web交互的过程(包括session),谢谢