xml，我觉得的两个优势：
1. 写复杂的 SQL 比较方便
2. 统一管理，有其他同事接手工作的时候，或者其他同事优化数据库查询的时候，位置好找，修改便捷，不容易出错

没有

想读个在职的~

房产税肯定会有一定的免征面积，反正我又没几套房子，刚好自住够用，不担心。

墙裂资瓷

^_^ 有故事的人

@jjww

谢谢指教，不过我有不同意见：

经过挖坑、填坑，我其实并不推荐 redis 来实现队列之类的，不确定性太多：
1. 如果我要查询历史消费记录，还是需要存储到其他稳定可靠的介质里面
2. 引入 redis 之后需要考虑维护其稳定性

如果真的是要扩展，我愿意上成熟的方案：例如阿里云的消息队列（当然如果有专门的基础组件研发团队，这又另说）

我们都是自备纸巾啊，用完了找行政拿，干净卫生


卫生间的纸我不太敢用

只要面向接口编程，以后把 MySQL 队列替换成 MQ 队列就很方便

那啥啥啥，小项目，完全可以就地取材，MySQL 也可以很好地实现消息队列的。。。反正我们小项目都用 MySQL 做消息队列了，多一个组件，多一份危险；大项目再上 MQ，保证 MQ 的高可用性需要花很多精力的。

假设数据表 tab_task 大致这样的：
seq_id, is_active, create_time, update_time

其中 is_active = 0 标示待消费的，is_active = 1 表示正在被处理，is_active = 2 标示已经处理好的。

--------------------------------------------------
正常消费线程，获取一个待处理任务（在一个事务中执行）：

UPDATE tab_task SET `is_active` = 1 AND `seq_id` = LAST_INSERT_ID(`seq_id`)
WHERE AND `is_active` = 0
ORDER BY `seq_id` ASC LIMIT 1;

SELECT * FROM tab_task
WHERE ROW_COUNT() > 0 AND `seq_id` = LAST_INSERT_ID();

----------------------------------------------------

定期检查超时的任务，然后发送报警，获取一个超时的任务（假设超时时间为 5 分钟）：

SELECT * FROM tab_task
WHERE is_active = 1 AND NOW() > DATE_ADD(`update_time`, INTERVAL 5 MINUTE)


--------------------------------------------------

需要注意的是，你自己的服务器、开放平台都能收到用户消息，而且能分别向用户推送消息

@edison111cry 对对对，就是微信开放平台哈

你自己的代码逻辑不用变啊，微信推送消息、推送事件的时候 既要推送给你，也要推送给绑定的开放平台中的应用

如果你开启了服务器配置又想方便修改菜单、设置自动回复等

这个时候可以接入使用一款第三方平台，三方平台走的专有接口，不会影响到你的服务端配置。

我们一般首次登陆时 scope = snsapi_userinfo，获取到 unionid, openid, 头像等，然后记录数据库

下次登陆时 scope = snsapi_base 获取到 openid 就可以用来登录了

---------------------------------------------------------------------------------------

你说的这种情况，完全可以设置一个刷新微信用户信息的时间间隔，超过一定时间再访问网页时，使用 scope = snsapi_userinfo 方式进行重定向授权，这样就可以解决用户信息不同步的问题了

@huangtao728 嗯嗯，这个比较切题，强烈感谢

@odirus 但要注意错误处理

例如 3 当用户在微信中没有进行授权，貌似也会回调，不过不会带上 code
例如 SCOPE 要合理选取，静默授权的话只能获取 openid，但要配合 APP 或者其他微信公众号，最好还是要获取 unionId，不然以后几个应用不能互相关联起来。

@edison111cry

第一步：
当用户请求某个页面（例如用户主页 http://test.com/home ）的时候（服务端正在处理，还未返回页面或接口信息的时候），服务端通过判断 cookie 中的 sessionid 发现用户未登陆或者登陆已失效，这时就不返回页面内容，而是让用户重定向到下面这个地址：

https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=SCOPE&state=STATE#wechat_redirect

其中 REDIRECT_URI 应该是 "http://test.com/openauth/wechat?redirect_uri=http://test.com/a" （注意转义哈，我这里只是用于讲解）

备注：假设你的业务系统中，专门处理微信授权登录功能的 URL 是： http://test.com/openauth/wechat

第二步：
拼装完 REDIRECT_URI 后，就是用户首先会跳转到的微信授权页面地址，大致流程是：
1. 当发现用户未登录的时候
2. 重定向到微信授权页面，授权成功后会跳转到 REDIRECT_URI
3. 根据 code 获取必要的信息（例如 openid 甚至是 unionId ）
4. 获取到了用户 ID，并执行了登录流程后，通过 cookie 写入 session 信息
5. 跳转到用户最开始真正需要请求的页面上

我们的方案是：

REDIRECT_URI （假设为 wechat_redirect_uri ）负责的职责：
根据 code 获取 openid 或者 unionId => 根据 openid 或者 unionId 查询用户 ID => 执行登录流程，并通过 cookie 写入 session 信息

REDIRECT_URI 中可以加入用户请求的目标业务的 REDIRECT_URI （假设为 user_redirect_uri ）

当用户授权之后，微信会回调到 wechat_redirect_uri 上，服务端处理完各种流程后，再回调到 user_redirect_uri 上


这种方案需要考虑在各个环节出错后的异常处理（例如 access_token 出错导致根据 code 获取 openid 不成功），避免一直在进行反复地回调跳转，用户会晕菜的。

加油