欢迎您来到“名字什么都是浮云”的博客空间!

常见问题

C# 定论:

1) 循环中的值就是迭代元素,一般不允许在迭代即循环时被修改,必须通过临时变量做转换

2) 方法参数不能在该方法中被修改,必须通过临时变量做转换

3) 类的公共属性或字段不能在类中被修改

 

来源路径:http://bbs.csdn.net/topics/392164212

  • 如何统计APP在线时长(允许有一定的误差),怎样判断用户是否还在线

    在全局应用程序类Global.cs中找到SessionStart开始事件和SessionEnd结束事件   

    在Session开始事件中定义Session保存登录时间和登录状态State,然后在Session结束事件中获得登出时间,并且清除登录状态,

    通过2个时间相减获得在线时长.通过登录状态判断用户是否在线

  • 数据库表中有一字段表示类型,不知道这个类型会有多少种,查出每个类型插入的最新一条数据
select * from(
    select  
    *, row_number() over(partition by Type order by id(主键) desc) rIndex 
    from 表名
) vw where vw.rIndex=1
  • 谈谈你对websocket、webapi的理解

  WebSocket是基于TCP网络协议。服务器主动发送信息给客户端.

  WebSocket原理:

  在实现websocket连线过程中,需要通过浏览器发出websocket连线请求,然后服务器发出回应,这个过程通常称为“握手” (handshaking)。在 WebSocket API,浏览器和服务器只需要做一个握手的动作,然后,浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送.

  服务器的推送,服务器不再被动的接收到浏览器的request之后才返回数据,而是在有新数据时就主动推送给浏览器。

  Web API是构建REST服务的平台,它支持MVC路由等功能,控制器,作用结果,滤波,模型绑定器,IOC容器和依赖注入,单元测试

  • 支付宝支付,微信支付,银联支付
    • 支付宝 
    1. 提交支付请求到支付宝获取支付宝POST过来通知消息,并以“参数名=参数值”的形式组成数组 
      1. 如果已经支付过则跳转到首页
      2. 查找没有支付的订单
      3. 支付类型,1为商品购买
      4. 服务器异步通知页面路径,需http://格式的完整路径,不能加?id=123这类自定义参数
      5. 页面跳转同步通知页面路径,需http://格式的完整路径,不能加?id=123这类自定义参数,不能写成http://localhost/
      6. 商户订单号,商户网站订单系统中唯一订单号,必填
      7. 订单名称,必填
      8. 付款金额,必填
      9. 防钓鱼时间戳,若要使用请调用类文件submit中的query_timestamp函数
      10. 客户端的IP地址,非局域网的外网IP地址,如:221.0.0.1
      11. 把请求参数打包成数组
      12. 建立请求
    2. 解读支付宝接口实现步骤
    3. 支付宝实现主要步骤:

       由两部分组成,接入部分与通知返回部分。

       接入部分即为传递参数等信息组合成超级链接,并用该链接来进行跳转。    

       通知返回部分则是支付宝服务器对该笔订单处理完毕后,通知与返回该笔订单的详细信息到商户服务器,商户服务器接收到后,并对其进行数据处理。

        • 接入部分原理
          • 选定参数信息
          • 排序
          • 加密
          • 拼接字符串成URL链接
          • 自动跳转
        • 通知返回部分原理
          • 验证是否是支付宝服务器发来的请求
          • 排序
          • 加密
          • 判断
          • 自身网站的数据处理
    • 微信支付
      • 参考路径:
      • 支付流程
        • 获取订单信息
        • 根据订单信息和支付相关的账号生成sign,并且生成支付参数
        • 将支付参数信息POST到微信服务器,获取返回信息
        • 根据返回信息生成相应的支付代码(微信内部)或是支付二维码(非微信内),完成支付。
      • 开发步骤
        • 客户端代码得到用户购买的商品信息,将之传给自己公司app服务器
        • app服务器调用微信“统一下单”接口,得到prePayId订单号并返回prePayId给手机客户端;
        • 手机客户端使用prePayId及商品信息调起微信客户端进行支付;微信客户端回调支付结果给咱们的APP客户端; 
          • 用户操作:输入密码进行支付;返回键取消支付;网络无连接支付失败等; 
        • 微信服务器异步通知咱们公司app服务器支付结果(服务器的工作,与客户端无关)
    • 银联支付
      • 参考路径:http://blog.csdn.net/chen504390172/article/details/16962905
      • 持卡人浏览商户网站,选择支付项目,生成订单信息
      • 持卡人确认订单信息,开始支付

      • 持卡人确认支付信息,商户网站开始向支付网关申请支付,支付网关验证商户身份合法性和订单报文的完整性

      • 支付网关向持卡人显示支付渠道选择界面,持卡人选择支付渠道

      • 持卡人在所选择渠道上,输入用户帐号、密码及其他安全验证信息 

      • 持卡人的安全认证信息得到确认后,进行支付
      • 支付渠道向支付网关返回支付结果

      • 支付网关向持卡人显示支付结果,同时通知商户网站支付结果

      • 商户网站向持卡人显示商户交易结果 

      • 支付操作完成。

  • 如果让你为APP提供数据接口,你会注意什么问题
    • 参考路径:http://blog.csdn.net/junli_chen/article/details/51180797
    • 跨平台性 
    • 良好的响应速度 
    • 接口要为移动客户端考虑 
    • 考虑移动端的网络情况和耗电量 
    • 通用的数据交换格式 
    • 接口统计功能 
    • 客户端与服务端的肥瘦平衡
    • 隐式用户与显式用户 
    • 安全问题  
    • 良好的接口说明文档和测试程序
    • 版本的维护
  • 在APP中,定位附近模块的数据你是如何提供的。假如A从当前位置(A1)向前移动了100/200/300米到了(A2)位置,A2位置商家信息,是如何到得的。
    • 基于百度LBS云服务提供了数据接口
    • APP中根据定位实现搜索附近(POI)的功能,采用百度LBS云服务,将所有POI数据上传后,可以实现该功能。
    • http://www.cnblogs.com/licin/p/6809603.html提供了获取移动app的坐标,然后获取商户坐标,根据2个坐标计算获得距离和位置。
  • 大数据 并发
    • 参考路径:http://blog.csdn.net/buynider/article/details/8655804
    • 常见情况
      • 大量的用户同时对系统的不同功能页面进行查找,更新操作

      • 大量的用户同时对系统的同一个页面,同一个表的大数据量进行查询操作

      • 大量的用户同时对系统的同一个页面,同一个表进行更新操作

    • 第1种情况一般处理方法
      • 对服务器层面的处理
      1. 调整IIS 7应用程序池队列长度
      2. 调整IIS 7的appConcurrentRequestLimit设置
      3. 调整machine.config中的processModel>requestQueueLimit的设置
      4. 修改注册表,调整IIS 7支持的同时TCPIP连接数
      • 对数据库层面的处理
      1. 什么都不做 –如果并发用户修改的是同一条记录,让最后提交的结果生效(默认的行为)
      2. 开放式并发(Optimistic Concurrency) - 假定并发冲突只是偶尔发生,绝大多数的时候并不会出现; 那么,当发生一个冲突时,仅仅简单的告知用户,他所作的更改不能保存,因为别的用户已经修改了同一条记录
      3. 保守式并发(Pessimistic Concurrency) – 假定并发冲突经常发生,并且用户不能容忍被告知自己的修改不能保存是由于别人的并发行为;那么,当一个用户开始编辑一条记录,锁定该记录,从而防止其他用户编辑或删除该记录,直到他完成并提交自己的更改
      4. 当多个用户试图同时修改数据时,需要建立控制机制来防止一个用户的修改对同时操作的其他用户所作的修改产生不利的影响。处理这种情况的系统叫做“并发控制”。

 

      • 管理数据库中的并发有三种常见的方法:
        • 保守式并发控制 - 在从获取记录直到记录在数据库中更新的这段时间内,该行对用户不可用。
        • 开放式并发控制 - 只有当实际更新数据时,该行才对其他用户不可用。更新将在数据库中检查该行并确定是否进行了任何更改。如果试图更新已更改的记录,则将导致并发冲突。
        • 最后的更新生效 - 只有当实际更新数据时,该行才对其他用户不可用。但是,不会将更新与初始记录进行比较;而只是写出记录,这可能就改写了自上次刷新记录后其他用户所进行的更改。
    • 第2种情况一般处理方法
      • 对表按查询条件建立索引
      • 对查询语句进行优化
      • 可以考虑对查询数据使用缓存
    • 第3种情况一般处理方法 
      • 先将数据保存到缓存中,当数据达到一定的数量后,再更新到数据库中
      • 将表按索引划分(分表,分区),如:对于一个存储全国人民信息的表,这个数据量是很大的,如果按省划分为多个表,在将全国的人民信息按省存储到相应的表中,然后根据省份对相应的并进行查询和更新,这样大并发和大数据量的问题就会减小很多

 

 

    1. 框架的类映射表,需要编写映射代码, 并且是很难维护的。 
    2. 可维护性,易于理解的代码,无需创造大的数据访问层。 
    3. 提供LINQ查询数据库,这需要从初级开发人员不太了解SQL。 
    4. EF可以用作用于数据服务和OData Service的基础设施。
    • 缺点:
    1. 实时的应用程序不利于EF同步。 
    2. 只能通过存储过程访问数据库。 EF的优势是:跟踪实体状态Change时,不仅仅在存储过程上.(即使EF确实对存储过程支持有限的)。 
    3. 频繁插入操作(Insert),  并且EF不支持大数据Bulk 插入。 
    4. 频繁更新操作,更新的目标主要是当多行(用一个单值) 
      • 例如:UPDATE 表名 SET ColumA = 10 Where ColumnB =? 
    1. 这种更新操作更好的使用的ExecuteNonQuery(也可从Context上下文或直接从Ado.Net)。 
    2. 反范式的表设计和高性能查询。 EF产生查询,他们是难以维护的,它并不能很好地支持映射到不规范的表。
    3. 对程序有非常的性能要求, 需要对每个查询进行监控.

 

 

 

    

posted @ 2017-05-05 19:01  名字什么都是浮云  阅读(256)  评论(0)    收藏  举报